Security Roles Examples within Microsoft Dynamics 365

Building a good security model

Building a good security model is a challenging process that requires careful planning and a thorough analysis of business requirements.

When a Common Data Service database is provisioned, it comes with a number of predefined security roles.

The System Administrator role

The System Administrator role offers full permissions and the most access to both data and configuration. This role cannot be edited or changed in any way.

System Customiser role

System Customiser role has full access to all custom entities by default, as well as record-level privileges of some variety for most system entities. This access varies from user-level to organisation.

Environmental Maker

Environment Maker can create new resources associated with an environment including apps, connections, custom APIs, gateways, and flows using Microsoft Flow. However, does not have any privileges to access data within an environment.

Common Data Service Users

Common Data Service Users can run an app within the environment and perform common tasks for the records that they own. Note: this only applies to non-custom entities.

Delegate allows code to run as another user or impersonate. Typically used with another security role to allow access to records.

When new privileges are required

As apps are built in the environment, new functionality and custom entities are introduced, and new privileges are required for the users to use the apps.

Adding to an existing role

The simplest approach is to add the privileges to an existing role within the app. You can do that by copying one of the predefined roles and then adding/removing privileges as requirev2CAd.

Note: It is strongly not recommended to modify any of the predefined security roles. That may introduce unexpected side effects in the existing functionality and during the environment updates.

Assigning multiple security roles

The most common approach to add additional privileges is to assign multiple security roles to a user or an owner team.

When users or owner teams are assigned to more than one role, they receive a combination of privileges and access levels for both roles. They are granted the least restrictive access level for that record type and privilege.

Contoso organisation

Let’s consider Contoso organisation, where Dynamics 365 Customer Engagement Sales and Customer Service solutions have been installed.

These solutions already come with a set of security roles to perform the most common sales and customer service tasks but Contoso would like to create a custom salesperson role to suit their specific business requirements:

In the above example, we can see that a user has been assigned two Security Roles.

• Common Data Services User Role provides the following:
  • User Access to Read, Write and Assign Accounts
  • No Access to Opportunities nor Cases
• Sales Person Security Role provides the following:
  • Organisation Read Access to Accounts
  • Business Unit Read Access to Opportunities
  • User Access to Edit and Assign Opportunities
  • No Access to Cases

As a result, the user gets all the privileges of all their roles:

The Actual Permissions that they get is the least restrictive based on the combination of both roles.

• Effective Permissions:
  • Organisation Read Access to the Account Entity
  • User Access to Edit and Assign Accounts
  • Business Unit Read Access to Opportunities
  • User Access to Edit and Assign Opportunities
  • No Access to Cases

In addition to the salesperson role, Contoso would like to create a custom role for sales managers.

Sales managers typically can perform all the tasks of a salesperson plus some tasks specific to their management role. This is where the layered approach can be used.

Note that the sales manager role by itself will not be sufficient for the user to access the app.

Instead, this role includes only the additional privileges specific to the management duties, such as broader access to the accounts and opportunities, and access to the cases to liaise with customer service.

The main benefit of the layered approach is that it grants a user additional privileges within the app by simply assigning an additional role specific to the task, instead of replacing their existing roles.

In our example, this can be used to give a sales user responsibility of a sales manager on either a permanent or temporary basis (for example, when a user is an acting sales manager).

Custom Entities

Additional consideration must be given to any custom entity that you create as part of the data model for your app.

None of the predefined roles, except for the system administrator, will include privileges to access data in the custom entities. The layered approach can be used to add these privileges.

Start with an empty custom role and only include the privileges for the custom entities included in your app. You can then include this custom role in your solution and enabled custom functionality simply by adding this role to the existing users.

In this video, Julie and George discuss and share some best practices as well as uncover some common mistakes for using security roles.