In this blog, we share a lesson learned when using a Dynamics 365 Customer Engagement online data source connector, called Instance Web API, for Power BI reports.
One of the truly powerful features of Microsoft Dynamics CRM as a business application platform is its built-in security tools. The security framework that CRM provides allows an organization to build security rules for their data and users with little need for advanced technical knowledge or database administration.
One misunderstood fact about CRM security, though, is that the use of business units within the security model will inherently silo data. For example, you often hear that because users "belong" to a single business unit that they won't be able to gain access to records that are owned by other users that are not part of the same business unit.
That is not inherently true. It is actually the combination of a user's security role, the security role's privileges (access rights), the access level of those privileges, and the owner of a record that define whether another user can read, write, or update, etc. a record.
To help understand how this works, consider the following definitions of the Dynamics CRM security components:
|Business Unit||A scoping mechanism that defines a grouping of users for security modeling purposes; business units are hierarchical in nature. Business Units are a framework upon which a security model is built.|
|Security Role||A collection of privileges (that are given a name) that reflect common user roles of your organization and/or business units; security roles are assigned to users or owner teams. See below for more details on Security Roles.|
|Privilege (access rights)||The definition of a specific type of data access or action that can be granted as a right; privileges are granted through a security role and are cumulative. The following Privileges that can be assigned:
|Access Level||While the Privilege defines the type of data access, the Access Level defines exactly to which records the privileges apply. You can assign the Access Levels of:
For example, if you assign Read privileges to a Security Role at the Access Level of "Business Unit", users with that Security Role will only have the privileges to see records owned by a user within their Business Unit.
For example, take the following security settings for the Salesperson security role on the account entity:
This combination will silo account records, meaning only a salesperson that belongs to the same business unit as the owner of an account record will be able to view that record. This is accomplished by configuring the settings as such:
But, if you change the access Level of these settings to either Parent: Child Business Units or Organization, this allows users from outside the owner's business unit to view the record. For example:
This configuration will allow a salesperson to view any account record that is owned by a user within their business unit or any child business unit.
And this configuration:
This combination will allow anyone to view account records, regardless of what business unit they are in, as the access level is set to Organization.
So, while you can use CRM 2013 business units to silo your data (it is indeed one of the most common reasons organizations utilize business units), it is not the inherit usage of business units that define whether the business units will silo data. Instead, it is the combination of the security role, privilege, and business unit-related access level that allows you to silo the data.
And you can imagine, with so many different configurations of these important security components (Business Units, Security Roles, Access Levels and Rights), the options are extremely vast. Understanding how these critical concepts work together will allow you to build complex and powerful security models into your CRM application.