Common Data Service Security 101

One of the key benefits of using Microsoft's Common Data Service is its highly customizable and robust permissions settings. With CDS, you can design a functional system tailored to your business. In order to do that, however, you need to understand the building blocks of this security architecture. Follow along for for a basic understanding of everybody's favorite topic: security! In this blog, I will be covering the standard security model in CDS. In a later blog, I will cover hierarchy security. 

Take a look at this diagram below of a basic business structure. It will be important in understanding how security is applied to entities.

In this example, we have set up an organization that includes the following breakdown of what the Sales department architecture may look like.

• Aerie (Organization Level)
  • Users in this business unit need to view data from all across many business units. Typical users are the C-Suite and System Admins
• Sales, Ops, Finance (Child Level 1)
  • The first level down from the Org business unit is the major departments at the company. Typical users here are the V.P.'s of the department.
• East, Central, West (Child Level 2)
  
  • The Sales department has many divisions, and we may need to permission the divisions to only see their account information. In this case, we have an East, Central and West division. Typical users at this level of the hierarchy are Sales Territory Managers.
• Enterprise Accounts, Small and Mid-Size Accounts (Child Level 3)
  • Each Sales division has sales people who target Enterprise or Small-Mid size accounts. We may need to permission their edit capabilities to each others data. In this case, the typical user would be a Sales Person.

Business Units

If your organization is structured around departments or divisions that have separate products, customers, and marketing lists, you might want to create business units. Business units are mapped to an organization’s departments or divisions. Below are the characteristics of Business Units.

• Roles created in your environment's default business unit replicate through all
• Every user must belong to one business unit and users can be assigned to any business unit in the hierarchy
  • This is important, because you need to assign the security role the right permission based on if they need to access just that particular business unit's records or the records of that business unit and its child business units.

Entity Ownership

Entities can either be owned by the organization or users/teams. You configure this setting when creating the entity. Once created, it cannot be changed.

• Organization-Owned
  • Entities owned by the organization.  A security role can either have permission to these, or not.
• User or Team-Owned
  • There are user or team-owned system entities. Because these records are owned by a user or team, they’re connected to a business unit and specific security roles for the business unit. Therefore, these entities participate in role-based security.

Security Roles

A security role defines how different users, such as salespeople, access different types of records. To control access to data, you can modify existing security roles, create new security roles, or change which security roles are assigned to each user. Each user can have multiple security roles. Security roles are characterized by the following:

• Grants permissions to entities
• Grants permissions to use Model Apps
• Each user can be assigned multiple roles, so for each user they are given the highest level of permission their combination of roles allows.
• Permission Items are as follows (CRUD, Append, Append To, Share, Assign)
  • None: User does not have permission to perform an action.
  • User: User has permission to perform the action for records that they own.
  • Business Unit: User has permission to perform the action for records owned by a user or team in the business unit they are in.
  • Parent: Child Business Units: User has permission to perform the action for records owned by a user or team in the business unit they are in and any child of that business unit.
  • Organization: User has permission to perform this action on any record in the system.
• Actions:
  • Create: action of creating a record.
  • Read: action of viewing a record and its metadata.
  • Write: action of editing a record and its metadata
  • Delete: action of deleting a record (point of no return).
  • Append: action of changing the lookup field values on a record.
  • Append To: action of changing the lookup field on a record for a particular entity.
  • Assign: action of changing the owner of a record.
  • Share: action of sharing a record with another user so that they can view or edit. 

Teams

A team template can be used for the entities that are enabled for automatically created access teams. In the team template, you have to specify the entity type and the access rights on the entity record. For example, you can create a team template for an account entity and specify the Read, Write, and Share access rights on the account record that the team members are granted when the team is automatically created. 

Access to Forms

Forms also have the ability to be hidden or shown to users based upon security roles. Sometimes you may need to design a form for one type of user versus another. 

Understanding these important facets of CDS Security will help you determine how your users will interact with your system in a productive and secure way.