Security Roles and Privileges in Dynamics 365

As one of the business tycoons mentioned, “Data is the new oil”. Nowadays organizations are pretty much worried about the data they own more over the security of the same. If that reaches the wrong hands, this same data can be used against the organizations. Its something like a double edged sword for the organizations like without data they cannot survive in this world and if they are not securing this data properly this same data can come against them. Controlling the data access helps the organizations to protect the sensitive data and at the same time enable collaboration between the users. This is where in Dynamics 365, we have business units, security roles, and field security profiles. In this blog, we will discuss one of the pieces of this puzzle Security Roles and Privileges.

Security Role defines how different users access different types of records in the system. To control the access to data, we can create or modify security roles or change the security role of that particular user. Each user can have multiple security roles assigned to them and remember that the security role privileges in Dynamics 365 is cumulative in nature, which means a user assigned to multiple security roles gets all the privileges of each security role they are assigned to. Each security roles can have record-level and task-based privileges.

• Record-Level Privileges defines which tasks a user with access to the record can do, like create, read, delete, write, assign, share, append and append to. Append means to attach to another record, and append to means to be attached to a record.
• Task-based privileges gives the user the ability to perform specific tasks in the system

Access level for a privilege is defined using the colored circles on the security role settings page. This determines how deep or high in the organization hierarchy the user can perform the specified privilege. The circles are defined as Global (), Deep (), Local (), Basic () and None (). Lets discuss little detail on each of these circles and what it means in the context of Dynamics 365.

• Global (Organization) : User can access all records in the organization, regardless of the business unit. These users automatically have all other privileges mentioned below. As this gives the highest level of access it should match the organization’s data security plan. Ideally this is given to those users who have control over the whole organization.
• Deep (Parent: Child Business Units) : Users can access all records in the business unit user belongs to and all its subordinate business units. Here also user automatically gets all privileges mentioned below this privilege.
• Local (Business Unit): User can access all records associated to his/her business unit. They automatically get all having access levels below this one.
• Basic (User) : User can access all records that the user owns, shared with the user and that are shared with a team that the user is member of.
• None: No access is allowed.

In CRM, there are eight different record level privileges that determine the level of access a user has to a specific record or record type. All these access levels works aligned with the security role of the user as well.

• Create: Required to create a new record.
• Read: Required to open a record to view the details.
• Write: Required to make changes or update a record.
• Delete: Required to permanently remove a record.
• Append: Required to associate the current record with another record. In case of N:N relationships, we must have Append privilege for both entities being associated or disassociated.
• Append To: Required to associate a record with the current record.
• Assign: Required to give ownership of a record to another user.
• Share: Required to give access to a record to another user while keeping our own access.

All users should have read privilege to the Web Resource entity else they wont be able to open a form that contains a web resource and will see an error similar to “Missing prvReadWebResource privilege”.

The owner of a record or a person who has share privilege on a record can share a record with the other users or teams. This can add Read, Write, Delete, Append, Assign and Share privileges for specific records. Teams are used primarily for sharing records that team members ordinarily couldn’t access. Its not possible to remove access for a particular record. Any change to a security role privilege applies to all records of that record type.

• User Privileges: Users are given the access directly when a security role is assigned to the user. User can create and has access to records created/owned by the user when Basic access level for Create and Read were given. This is the default setting for new security roles.
• Team Privileges: User is given access via a team or as the member of the team. If the user don’t have privileges of their own, then they can create only with the team as the owner and they have access to records owned by the team when basic access level for create and read were given.

To create a new security role, the user should have System Administrator or System Customizer security role or equivalent permissions. It can be created via Settings -> User’s + Permissions -> Security Roles. In order to assign security role to a user we need to have minimum Read and Assign privileges on the Security Role entity. Again the user who is assigning the security role cannot assign someone else with a security role that has more privileges than the assignee. This is to make sure no user is elevating their security role to a higher role resulting in accessing the data which they are not supposed to.

If we can design a security matrix which will fit the business needs of an organization, using the Business Units, Security Roles, Hierarchy Modelling, Teams and all other pieces related to the security model of Dynamics 365 can be used in a flexible manner to achieve our goals without compromising on the data security. Hope this blog was useful and thanks for your time reading this blog.