Skip main navigation

Role Examples

Microsoft Dynamics 365 and the Power Platform

In the previous step, we explored Privilege and Access Levels. Now, let’s discuss Security Roles Examples.

Building a good security model is a challenging process that requires careful planning and thorough analysis of business requirements. When Common Data Service database is provisioned, it comes with a number of predefined security roles.

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 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.

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 User 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.

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.

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.

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, the 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.

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 most common sales and customer service tasks but Contoso would like to create a custom salesperson role to suit their specific business requirements:

image "Image of custom salesperson role"

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, user gets all the privileges of all their roles:

image "Image of user with all privileges of 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 sales person role, Contoso would like to create a custom role for sales managers. Sales managers typically can perform all the tasks of a sales person plus some tasks specific to their management role. This is where layered approach can be used.

image "Image showing layered approach"

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.

image "Image showing cumulative privileges for the user"

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.

Up Next, we explore Configure Hierarchy Security.

This article is from the free online

Dynamics 365: Using Power Platform Applications

Created by
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now