Dynamics CRM – Security Model – Part 01

Introduction

Dynamics CRM security is a critical aspect when it comes to implementing CRM solutions. If the security model is not designed properly, then you might end up in wrong people accessing wrong information and also you could end up putting sensitive information in wrong hands which could have severe consequences. In this article, I will try to give you a detailed picture about how Dynamics CRM Security model works, and how you can leverage some of the out of the box security features to better design the security aspect of your CRM solution.

First let’s look at the purpose of the security model. It is not only to provide user access, but also it defines what types of actions the users can take against the records. It does this by considering who is the user performing the action and who is the owner of the record. It also helps you to expose different forms based on the user’s positions within the organization. That is you can create different versions of the form for the management, supervisors and workers for the same record. This also allows you to control which dashboards different users have access to. Assume that you are working with contractors, or temporary employees, like sales persons. You can prevent them from exporting any data from the CRM solution. You can do this by controlling access to features. Event you can control the print rights. The Dynamics CRM Security Model simplifies the user experience. For instance, rather than having features or fields that a particular does not have access to, it simply hides them based on the privileges they have. Basically it controls how the users are working within the application.

Security Roles

Security roles basically defines what specific permissions a user/team has on particular item within the application. Within the security role, we use the privileges and access levels to define the permission to specific items. So the security roles are a critical aspect within the application, because every user who intend to use the application has to have at least one security role associated with them. Security roles also gives you some finite control over custom entities.

There are few different options when assigning security roles:

  • You can just create a security role and assign user(s) to that role.
  • You can assign a user to a role based upon their user interface.
  • You can also use out of the box security roles as it is and assign users to them
  • Or you can customize the out of the box security roles and use them as per your requirements.
  • You could also copy the existing role and modify it, in scenarios where you want retain out of the box security roles

Privileges

When it comes to designing security for your CRM solution, there are two elements that make up the user access to the application. Those are called Privileges and Access Levels. Privileges are considered as the most basic security unit of Dynamics CRM and they define what particular action that a user can perform against each particular entity. For instance to create Contacts, read Accounts, update Invoices, delete Cases, etc. There are 8 common privileges.

  1. Create: Allows the user/team to create records of the entity. For instance enabling user(s) to create accounts, contacts, etc.
  2. Read: Allows the user/teams to view the records of a particular entity.
  3. Write: Allows the user/teams to write or make changes to entity records. Basically the update rights to the entity.
  4. Delete: Defines whether the user/team can delete the records of an entity.

The other 4 are basically related to records sharing, which means that whether other people can view or use the records owned by you or using them with other records for certain business processes.

  1. Append: This allows user/teams to attach a record to other record. For instance if you want to add the primary contact record to your account then you must have append privileges for the contact entity.
  2. Append to: Basic idea behind this is, can I attached records to that specific records. On the context that I have to append contact to account records, I have to have append to privileges on the account entity.  If the user/team does not have append to privileges, they cannot associate any records to it, no matter what other privileges they have.
  3. Assign: This is basically means that the user/team can transfer the ownership of record(s) to another user/team.
  4. Share: Sharing enables user/teams to overwrite the current record access for the short period of time. For instance, if I am going on vacation, I should be able to share my accounts to my colleague while I am away.

Access Levels

As we discussed before, privileges define whether I could create, delete, view or update records. So the access levels define to which extent I can perform the actions. That is, you can provide different levels of access to each one of the privileges we discussed. It is illustrated in the below diagram.

crm31

If you look at it from the application perspective, there will be 5 levels of access levels as highlighted in the above diagram. Let’s look at each access level in detail.

  1. None Selected: This means that the user does not have the particular privilege for a particular entity. For instance, as you can see below, the Sales Manage role does not have Create, Write, Delete, Append and Append to rights to Business unit.

crm32

  1. User: This defines the access level to the record(s) that you own of a particular entity. As illustrated in the below image, the salesperson role will have only user access level to Activity and Client records. That is, if a user with the Salesperson role creates an activity or a Client record, then the created user will be the owner. Also notice that the Delete privilege will be user level to ensure that if a record is deleted, only the record owner will delete it. This applies to the teams as well. That is if a record is owned by a team, then the members of the team can manipulate the record.

crm33

  1. Business unit: At this level, you can manipulate the records owned by you or members of the team that you belongs to or the members of the same business unit. For instance, if you have been assigned with Knowledge Manager role, you will be able to Write to Invoices owned by the business unit you belongs to. You will also be able to write to Invoices owned by you as well.

crm34

  1. Parent Child Business unit: At this level, you can manipulate records owned by you/team, and members of the same business unit as well as parent business units of the business unit you belongs to and child business unit of your business unit. For instance, as illustrated in the below image, if you are given the salesperson role, you will be able to write to Marketing Lists owned by you/team, the business unit you belongs to, and any parent or child business unit of your business unit. You need to keep in mind that your access level is vertical, but not horizontal. That is, you cannot manipulate any records owned by other business units.

crm35

  1. Organization: This defines, that I can perform the privilege on any record, at any level regardless of who owns the record(s). Normally for some security roles, we give read access at organization level as illustrated below.

crm36

But if you navigate to System administrator role, you can see that it has full organizational rights to everything.

crm37

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s