Looking for PowerObjects? Don’t worry, you’re in the right place! We’ve been part of HCL for several years, and we’ve now taken the final step in our acquisition journey: moving our website to the HCL domain. Nothing else is changing – we are still fanatically focused on Microsoft Business Applications!

PowerObjects Blog 

for Microsoft Business Applications

Microsoft Dynamics CRM 2013 Business Units and Data Silos

Post Author: Joe D365 |

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:

Component Description
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:

  1. Create
  2. Read
  3. Write
  4. Delete
  5. Append
  6. Append To
  7. Assign
  8. Share
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:

  1. None
  2. User
  3. Business Unit
  4. Parent: Child Business Unit
  5. Organization

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:

CRM 2013 Business Units and data silos

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:

  • Security Role = Salesperson
  • Privilege (Access Right) = Read
  • Access Level = Business Unit

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.

  • Security Role = Salesperson
  • Privilege (Access Right) = Read
  • Access Level = Parent: Child Business Units

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.

  • Security Role = Salesperson
  • Privilege (Access Right) = Read
  • Access Level = 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.

Happy CRM'ing!

By Joe D365
Joe D365 is a Microsoft Dynamics 365 superhero who runs on pure Dynamics adrenaline. As the face of PowerObjects, Joe D365’s mission is to reveal innovative ways to use Dynamics 365 and bring the application to more businesses and organizations around the world.

2 comments on “Microsoft Dynamics CRM 2013 Business Units and Data Silos”

  1. Hello,
    interesting and clear article!
    I am trying to setup the following scenario
    - two users U1 and U2 both belong to business units B1
    - an account AC1 is owned by U1
    - both U1 and U2 are salesperson
    - I set up security for SalePerson role and for accounts entity to "Business Unit parent-chid"
    - I was expecting that both user can view account AC1 in their public view such as "Active accounts"

    But this is not the case.
    Account ACC1 appears only in the lisf of "personal" accounts of it's owner, no way for u2 to view the record.

    Any idea ?

    Thank in advance.
    SQL Server MCT

  2. I am also facing the same issue as Alberto.
    For eg: I as an admin assigned an opportunity to User A. The security role of User A allows hime to Read all opportuhnty records in Parent:Child Business Unit.
    But User A can see this opportunity only from the "My Open Opportunities" and not from "Open Opportunities"
    Whatever the user sees in "My Open Opportunities" should appear in the "Open Opportunities" as well.
    I checked the view definition and there is nothing that should hinder this opportunity from appearing

PowerObjects Recommends