Bhoopathi

"Be Somebody Nobody Thought You could Be"

Wednesday, August 24

MS CRM :: The security model of Microsoft Dynamics CRM

The security model of Microsoft Dynamics CRM:

Role-based security: 
                                                In Microsoft Dynamics CRM focuses on grouping a set of privileges together that describe the responsibilities (or tasks that can be performed) for a user. Microsoft Dynamics CRM includes a set of predefined security roles. Each aggregates a set of user rights to make user security management easier. Also, each application deployment can define its own roles to meet the needs of different users.

Record-based security: 
                                                In Microsoft Dynamics CRM focuses on access rights to specific records.

Field-level security:        
                                                In Microsoft Dynamics CRM restricts access to specific high business impact fields in an entity only to specified users or teams.

Access levels:

  • Global. This access level gives a user access to all records within the organization, regardless of the business unit hierarchical level to which the instance or the user belongs. The application refers to this access level as Organization.This level of access is usually reserved for managers with authority over the organization.

  • Deep. This access level gives a user access to records in the user's business unit and all business units subordinate to the user's business unit.The application refers to this access level as Parent: Child Business Units.This level of access is usually reserved for managers with authority over the business units.

  • Local. This access level gives a user access to records in the user's business unit.The application refers to this access level as Business Unit.This level of access is usually reserved for managers with authority over the business unit.

  • Basic This access level gives a user access to records he or she owns, objects that are shared with the user, and objects that are shared with a team of which the user is a member.The application refers to this access level as User.
  • None. No access is allowed.

Putting it all together

  • If a user has the Deep Read Account privilege, this user can read all accounts in his or her business unit, and all accounts in any child business unit of that business unit.
  • If a user has Local Read Account privileges, this user can read all accounts in the local business unit.
  • If a user is assigned the Basic Read Account privilege, this user can read only the accounts that he or she owns or the accounts that are shared with him or her.
  • A customer service representative with the Basic Read Account privilege can view accounts that he or she owns and any accounts another user has shared with this user. This makes it possible for the representative to read the account data that is relevant to a service request, but not to change the data.
  • A data analyst with the Local Read Account privilege can view account data and run account-related reports for all accounts in his or her business unit.
  • A finance officer for the company with the Deep Read Account privilege can view account data and run account-related reports for all accounts in his or her business unit and accounts in any child business unit.

Plug-in Images (Pre vs. Post)

Images are snapshots of the entity’s attributes, before and after the core system operation. Following table shows when in the event pipeline different images are available:
Message
Stage
Pre-Image
Post-Image
Create
PRE
No
No
Create
POST
No
Yes
Update
PRE
Yes
No
Update
POST
Yes
Yes
Delete
PRE
Yes
No
Delete
POST
Yes
No

The benefits of images

  • One of the best uses for this is in update plug-ins. As mentioned before, update plug-in target entity only contains the updated attributes. However, often the plug-in will require information from other attributes as well. Instead of issuing a retrieve, the best practice is to push the required data in an image instead.
  • Comparison of data before and after. This allows for various audit-type plugins, that logs what the value was before and after, or calculating the time spent in a stage or status.
Pre vs. Post images:

  • Plugins in Dynamics CRM, allow you to register images against the steps of a plugin assembly. Images are a way to pass the image of the record that is currently being worked upon prior or after the action has been performed. In general it could be said, it is the image of the record as is available in the SQL backend.
  • Two types of Images are supported, Pre-Image and Post Image.
  • In case of Pre-image, you get the image of the record as is stored in the SQL database before the CRM Platform action has been performed.
  • Post Image, returns the image of the record after the CRM Platform action has been performed.