Apps that you build require access to data in the Common Data Service (CDS). You need to understand how to apply security to restrict a user's access to data and functionality. You can also control access to environments and apps through the different layers of security. 

Security is a broad topic, and the CDS has a wide set of security features that are discussed in this chapter. The chapter will begin with an overview of the available features and will then concentrate on the security features you are likely to employ within your systems.

In this chapter, we will cover the following topics:

• Overview of the available security features
• Security in the CDS
• Users and teams
• Hierarchical security
• Field-level security

By the end of this chapter, you will be able to employ the appropriate security features, create and manage security roles, enable field-level security, enable hierarchical security, and manage user and team security.

Overview of security features

The control of access to data and functionalities is extremely important in any system. The CDS has a powerful and flexible security model that can be configured to meet many different security requirements.

Security is controlled by different products, such as the following:

• Azure Active Directory (AD) handles the authentication of users.
• Office 365 and Azure AD manage users and their licenses.
• Access to environments can be restricted in the Power Platform admin center.
• CDS databases manage security, authorizing the use of data and services within applications.

Security in the Power Platform and CDS is provided by multiple layers, all aimed at ensuring users can only access the apps, features, and data they need and no more. The following diagram shows the layers of security in the Power Platform:

Before we look at these capabilities and features of security in the CDS, we need to consider the security aspects of the cloud.

Cloud security

The CDS runs on the Microsoft cloud as a service on top of Azure. The CDS inherits security, privacy, and compliance protections from Azure, leverages other security features to protect your data and apps, and assists in your compliance with the General Data Protection Regulation (GDPR) and other privacy initiatives.

Because the CDS runs in the cloud, Microsoft has enabled multiple security protections for your apps and data.

Securing data with encryption

Your data is encrypted at rest using SQL Server Transparent Data Encryption (TDE). There is a default encryption key generated for each CDS database that you should manage and make a safe copy of.

All data is secured in transit between the Microsoft data centers and your devices.

Authenticating apps

The authentication for your apps, maker portal, and admin portals is handled by Azure AD. This means you inherit all the capabilities of Azure AD for your apps including multi-factor authentication, Conditional Access policies, identity protection, Business-to-Business (B2B) access, and Single Sign-On (SSO).

SSO adds both security and convenience for users. SSO enables users to access apps by logging on only once to their PC and Azure AD. Users are not prompted to access Dynamics 365 or Power Platform apps again, with SSO handling authentication on your behalf. Once authenticated, the Power Platform then authorizes access to your environments.

Environment security

An environment is a container for your data, apps, and flows; you first learned about environments in Chapter 2, Power Platform.

Each environment is controlled by the security functionalities to restrict who can access the environment. The access to such security functionalities is different depending on whether there is a CDS database in the environment or not.

Environments can be linked to an Azure AD security group. Once linked, only users in that security group will be able to access that environment.

Without a CDS database, access is controlled by users being given either of the following roles on the environment:

• Environment Maker
• Environment Admin 

Once a CDS database has been added to an environment, access is controlled by CDS security roles. Users must have a security role to be able to access data in the CDS database.

Security in the CDS

The CDS is not just a data store for your apps to read and write data. The CDS has a comprehensive set of security features that you can employ in your Power Platform system.

This section will describe the various features so that you can decide which feature(s) map to your security requirements. As shown in the following diagram, the CDS has a set of complementary security features that control access to data, features, and apps:

You will learn about these features in the following sections. First, we will look at the cornerstone of security, business units.

Business units

Business units provide the basis for security within the CDS. A business unit is a security boundary used to control access to data.

Business units can be arranged in a hierarchy such as in the following diagram:

Every CDS database has a business unit automatically created when the database is created. This is known as the root business unit and is normally named after the environment's name. The root business unit cannot be disabled or deleted.

You can create business units, but these child business units must always have a parent business unit; only the root business unit cannot have a parent. Unlike the root business unit, child business units can be disabled and deleted.

You manage business units from your environment's settings in the Power Platform admin center. The following screenshot shows an example list of business units:

The business hierarchy reflects your organization's internal structure. However, you should not simply replicate your org chart; instead, you should create your business unit hierarchy to meet the needs of your security requirements. Users will never see business units in model-driven apps and should not be aware of them. It may be sufficient for your needs to just have the single root business unit, or you may require multiple business units to control access by functional areas or by geography, or even a combination of function and region, as shown in the preceding diagram.

Business units work with security roles to determine a user's access to data.

Security roles

The CDS employs the concept of Role-Based Access Control (RBAC). Note that roles within the CDS are referred to as security roles. A security role is a collection of privileges and access levels. There are several security roles provided to enable you to get started quickly, for example, the Common Data Service User role shown in the following screenshot:

There are two types of privilege contained in a security role:

• Record-level: For entities and records
• Task-based: For specific features or operations

The following screenshot shows some of the record-level privileges in a security role:

As shown in the previous screenshot, record-level privileges define the operations that a user can perform for each entity, and for the records of that entity:

• Create: Used to create a new record.
• Read: Used to view records.
• Write: Used to edit or update records.
• Delete: Used to delete records.
• Append/Append To: These work in combinations of one-to-many and many-to-many relationships to control whether one record can be attached to another record. 
• Assign: To change the ownership of a record to a different user or team.
• Share: To share a record with another user or team.

These privileges affect the user interface for model-driven apps, such as in the following examples:

• If a user does not have at least read access on an entity, then that entity will not be shown in the model-driven app; it will not be shown in the navigation or appear in Advanced Find.
• If a user does not have the Create privilege for an entity, then the + NEW button will not be shown in the action bar.
• If a user does not have the Delete privilege on a record, then the delete icon will not be shown in the form for that record.
• If a user does not have the Append To privilege on a record, then they will be unable to attach other records to it such as phone calls, tasks, emails, and other types of activity.

The following screenshot shows some of the task-based privileges in a security role:

As shown in the previous screenshot, task-based privileges permit a user to perform specific tasks, such as exporting to Excel, merging records, or using the app for Outlook. Typically, these privileges will be buttons in the action bar of a view or a form. If a user does not have the privilege for a task, the related button will not be shown on the action bar.

You will have noticed that in the previous screenshots, each privilege is represented by a circle and that the circles have assorted colors.

Access levels

Access levels are where the privileges are combined with the business unit hierarchy to determine the privileges for each record. The following screenshot shows how access levels are represented on the security role page:

As shown in the previous screenshot, there are five access levels:

• None: An empty circle with a red boundary. This means the user will not have this privilege.
• User: A quarter-filled yellow circle. If a user owns the record, they will have this privilege.
• Business Unit: A yellow semi-circle. If a user is in the same business unit as the record, they will have this privilege.
• Parent: Child Business Units: A three-quarter-filled green circle. If a record is in the same business unit as the user, or in a business unit in the hierarchy underneath the user, they will have this privilege.
• Organization: A green solid circle. This means the user will have this privilege on all records.

This is easier to understand with an example:

In the preceding example, the security role has the following access levels for an entity's privileges:

• Create User: The user will be able to create a record, but they will not be able to change the owner of the record before saving; that is, they will be the owner of the record.
• Read Organization: The user will be able to see all records for the entity, no matter who owns the records, or where the user is in the business unit hierarchy.
• Write Business Unit: The user will be able to update records they own, and any record owned by users in the same business unit.
• Delete None: The user will not be able to delete any records for the entity even if they own the record. 
• Append Organization: The user will be able to link this record to a parent record, that is, for a many-to-one relationship.
• Append To Organization: The user will be able to link other records for entities in a one-to-many relationship.
• Assign User: The user will be able to change the ownership, but only on records where they are the owner.
• Share Parent: Child Business Units: The user will be able to share records they own, records owned by users in the same business unit as the user, and records owned by business units in the hierarchy underneath the user's business unit.

Where there is a many-to-many relationship between two entities, the Append and Append To privileges are required on both entities in the relationship. Organization-owned entities have only the None and Organization access levels; that is, they are on/off or all/nothing.

Business units, users, and security roles

Business units are the cornerstone of security in the CDS. All users must belong to one, and only one, business unit. A user's access to records flows from their place in the business unit hierarchy.

This section explains how business units, users, and security roles come together to give users access to data. Security starts from the hierarchy of business units and the location of a user within this hierarchy. The following diagram shows an example business unit hierarchy with users assigned to different business units:

Let's look at the Read Account privilege for a security role using the business unit hierarchy in the preceding diagram:

• A user in the North business unit with a Read Account privilege access level set to Business Unit will be able to view accounts that they own and accounts that are owned by the other users who are in the North business unit.
• A user in the Sales business unit with a Read Account privilege access level set to Parent: Child Business Units will be able to view accounts that they own, accounts owned by the other users who are in the Sales business unit, and all accounts owned by users in the North, Central, and South business units.
• A user in the Operations business unit with a Read Account privilege access level set to Organization will be able to view any account, no matter who owns it or where the owner is in the hierarchy.

Now that you have seen how security roles work with access levels and privileges, you need to know how to create security roles and change the access levels.

Creating or modifying security roles 

There are several security roles provided out of the box to enable you to get started quickly. You can edit these roles, copy and edit the roles, or create new custom roles from your environment's settings in the Power Platform admin center:

When you copy a role, you give it a name and all the access levels are copied for each privilege. 

You cannot create new privileges yourself but when you create a custom entity, create, read, write, and other privileges are created for you. When you edit a security role you are restricted to just changing the access levels on each privilege.

To change an access level for a privilege, you simply click on the circular icon and it will rotate through the access levels from None to User to Business Unit to Parent: Child Business Units and then to Organization. If you click again, the access level will change to None.

The out-of-the-box roles are named after job roles, for example, Salesperson, and are aimed at providing all the privileges that the job requires. You can follow this model of roles for specific job roles, but you may end up with many security roles that are similar and that you must maintain. For example, adding a new custom entity means editing many, if not all, the roles.

A more modern model is to use a layered security model. In this model, you would copy an out-of-the-box role, such as Salesperson or Common Data Service User, and change the access levels to the common, or minimal, levels that all users require. You might name this role Base, or All Staff. You would then create new roles and just set the access levels for the few privileges that each group of users would need in addition to the base role. 

The following diagram shows how layered security roles function. All users will be assigned the All Staff role. Salespeople will also be assigned the Sales role with sales managers also having the Manager role. Salespeople who need to travel to customers can also be assigned the Mobile role. Operations staff will have the Operations role assigned, with operations managers also having the Manager role:

This model is much easier to manage; for example, adding a new custom entity may just require you to edit the base role.

You assign the base role and additional roles to each user. When you add multiple roles to a user, you need to understand how the privileges and access levels are combined.

Assigning multiple security roles

When you assign multiple roles to a user, the effective security a user has is cumulative. It is a union of least restrictive privileges.

You need to work out effective security practices on a privilege-by-privilege basis. There is no tool provided that performs this analysis for you.

For example, three security roles have the following access levels on the Update privilege for the Contact entity:

• None
• User
• Business Unit

The effective privilege is the least restrictive of these, that is, Business Unit.

In another example, three security roles have the following access levels on the Assign privilege for the Activity entity:

• User
• Business Unit
• Organization

The effective privilege is the least restrictive of these, that is, Organization.

In the following screenshot, you can see the result of the combined security roles:

Security roles also have a purpose outside of a user's data and functionality access – they can be used to restrict access to apps and user interface components.

Roles in model-driven apps

Model-driven apps must be associated with one or more security roles before they can be run by users.

In the classic interface, you added one or more security roles to your app after creating the app by clicking on Manage roles.

In the maker portal, the new method is to share the app with one or more security roles. This matches the model for distributing canvas apps. In either method, you are associating the app with one or more security roles.

Users will then be able to see and run an app if they have one of the same roles as the app.

Roles in other components

Security roles can be used to restrict access to the following user interface components in the CDS and model-driven apps:

• Forms
• Dashboards
• Business process flows

You cannot control access to the following components with security roles:

• Fields
• Charts
• Views

Now that we have identified all the security features, you need to learn how these features are applied to users.

Users and teams

All users of the Power Platform are authenticated by Azure AD, as described earlier in the chapter. You will now discover how users are set up.

Users in Microsoft 365

Microsoft 365 uses Azure AD to manage users and handle authentication and authorization when a user attempts to access an app or data in the Power Platform. You can use either the Microsoft 365 admin portal (https://admin.microsoft.com/Adminportal/Home#/homepage) or the Azure AD portal (https://aad.portal.azure.com) to create and manage users. A user must be assigned a license in Azure AD.

Managing users in Microsoft 365 or Azure AD is out of scope for the PL-200 exam. A functional consultant will not be responsible or have permission for this level of administration.

Users in the CDS

Users in a CDS database are created automatically when a user is given a license. Users are created in the root business unit and, except for users with administration roles, are not given a security role and are therefore prevented from accessing the CDS.

After creating a user, you will need to do the following:

• Change the user's business unit so that they are in the correct place in the hierarchy.
• Apply one or more security roles to the user.

You manage users, along with the other security features covered in this chapter, from the Settings window for your environment in the Power Platform admin center, as shown in the following screenshot:

You can now associate your new user with one or more teams, but first, you need to understand how teams are used in the CDS.

Record ownership

When you create an entity in the CDS it can either be user-, team-, or organization-owned.

Entities that are user- or team-owned have the additional Assign and Share privileges compared with organization-owned entities. The Assign privilege is concerned with record ownership. When you create a record, you become the owner of that record.

If you own a record, the record also belongs to the business unit that you are in. This is how the business unit/security role model works. If you change your business unit, your records move with you, and their business unit is changed also.

It is common to set up security so that users can only access their own records, or records in their department, using business units and security roles. In some circumstances, a user may need access to a record they do not have rights to – this is what the Share privilege is for.

Sharing

In the security model, the concept of sharing has been provided so that a record can be accessed by a user who does not have access through the security model. You can share a record with other users and teams.

The Share privilege permits a user to share a record. If a user does not have the Share privilege on a record, the Share button will either be disabled or even hidden in the user interface.

When a user shares a record, the user specifies the privileges the other user or team will have, out of Read, Write, Delete, Append, Assign, and Share:

You can also share the following:

• Personal views
• Personal charts
• Excel templates
• Word templates

It is better to share with teams as it reduces the management overhead.

Teams

There are several reasons to create teams. A team could be a group of people who work together for a long time, for example, a department; or temporarily, for example, a project team.

There are three types of teams:

• Owner teams
• Access teams
• Azure AD security group teams

Owner teams

Owner teams can have security roles applied and can therefore own records and have records shared with the team. You create owner teams manually and add users as members of the team.

Teams must belong to a business unit but can have members from other business units. This is the method by which we can breach the strict hierarchy of the business unit/security role model. For instance, an owner team can be created for the Central business unit, but it might contain members from the Operations business unit. A record owned by this team will be accessible by members of the Operations business unit even if their security role provided only the business unit access level to the entity.

Sharing a record requires the user to access a non-intuitive user interface and understand the privileges shown. Most users struggle with this and access teams exist to make the action of sharing a record as simple as possible.

Access teams

Access teams are created automatically by the system when you add a user to a special sub-grid on a form; in Dynamics 365 Sales there is an example of such a sub-grid on the Opportunity form, called Sales Team.

When you add a user to such a sub-grid, the system does the following:

• Creates an access team
• Adds the user as a member of the new team
• Shares the record with the new team

The main benefit of access teams is that the user does not have to specify the privileges to be shared; instead, an administrator creates an access team template that specifies the privileges provided. All the user has to do is add another user to the sub-grid on the form.

The process to add a sub-grid is as follows:

1. Enable the entity for access teams.
2. Create an access team template.
3. Add a sub-grid of users to the entity form.
4. Select the access team template.

One of the advantages of access teams is that you can query and see what records are shared with which users. It is not possible to find out what records are shared with owner teams.

Azure AD group teams

You can connect a team to an Azure AD security group. This has many advantages for user management, as the membership of a team in the CDS is managed by the Azure AD group membership.

Azure AD security groups operate like owner teams; they can have security roles applied and can own records.

The security model is based on the business unit hierarchy, and although you have seen how we can bypass the hierarchy with teams, there are still business needs that require different hierarchies, which is confusingly called hierarchical security.

Hierarchical security

Hierarchical security is an alternative to the strict business unit and security role model. Instead of using business units and security roles, security is based on who reports to whom.

In this model, your user has read and write privileges on all records for the users who directly report to you. Your direct reports have read and write privileges for the users who report to them and you have read privileges on those users' records as well.

To summarize, with hierarchical security you have the following options:

• Read and write privileges for one level below you
• Read privileges for the levels beneath that

This is a common model for sales teams, where sales managers need to have full access to their team's data. It is even more useful where you have people working across different regions and you have to set up your business units based on geography.

You have two options:

• Manager: Based on the manager field on each user record
• Position: Based on a position that is assigned to users:

Hierarchical security is off by default and must be enabled. Then you can choose one of the security hierarchy options, either Manager or Position.

Manager hierarchy

The manager hierarchy is restrictive as it works within the business unit structure.

The rule for allocating a manager to a user is that the manager must reside in the same business unit as the user, or in one of its parent business units. So, in our example business unit structure, a user in the Central business unit can only be managed by a user in the Central, Sales, or Root business units.

The manager hierarchy is useful if you already use the manager field, for example, in your workflow.

Position hierarchy

The position hierarchy is much more flexible; it ignores the business unit structure so you can easily apply this model alongside your existing business unit structure without complications.

There is an entity called Position. You create your positions and their hierarchy and then assign those positions to users. Positions allow the spanning of business units so a user in one business unit can access the records of a user in a subordinate position, no matter which business unit that user is in.

Another benefit of the position hierarchy is that a user can only have one manager; with positions, you can have more than one person in a position, thus allowing greater access where there are shared management responsibilities.

All the security models so far have been concerned with access to records; the read or write privileges are for the record and all fields in the record, but you may require certain fields within an entity to be restricted. Field-level security is the method by which we can control access to fields.

Field-level security

In the CDS, once you have access to a record via security, you have access to all fields for that record. Even if the fields are not on the form, you can access the fields using Advanced Find or using the Web API. 

The CDS supports setting fields to secured to restrict access to the field's contents.

Secured fields

Setting a field to secured will prevent users from being able to view or set the value of the field. You enable fields for field-level security when creating or editing a field. The following screenshot shows you how to secure a field:

You can set most fields to secured, including system and custom fields. Exceptions are fields such as createdon, statecode, and ownerid.

On the form, the field will appear with a key symbol next to the label and the contents will be shown as empty or masked with asterisks:

After a field is enabled for field-level security, only users with the System Administrator security role will be able to set and view the contents of the field. To allow other users to access the contents of a secured field, you will need to create a field security profile.

Field security profiles

Field security profiles simplify the setting of permissions on secured fields by grouping secured field permissions into a profile that can be assigned to users and teams. This eliminates the need to set the permission on each secured field for each user.

Field security profiles control which users can access which secured fields. A field security profile contains the following:

• Field permissions: The permissions on all secured fields
• Service principals: Users and teams that belong to the field security profile

Field security profiles are components that can be added to solutions. You create a field security profile from within a solution in the maker portal.

For each secured field, you can set three permissions:

• Read: Allows the user to read or view the contents of the field
• Update: Allows the user to change or overwrite the contents of the field for an existing record
• Create: Allows the user to set the contents of the field when creating a record

The field permissions are illustrated in the following screenshot:

Common combinations for permissions are as follows:

• Read-only: Allow Read set to Yes, Allow Update and Allow Create set to No
• Password/PIN: Allow Read set to No, Allow Update and Allow Create set to Yes

Once you have set the field permissions, you add the user(s) and/or team(s) as members of the field security profile.

Just like security roles, a user can belong to more than one field security profile. When a user has more than one profile, the user has the least restrictive combination of permissions. That is, if one profile has a secured field set to Not Allow Read and another profile has the field set to Allow Read, then you will have Allow Read permission.

Congratulations on reaching the end of this chapter. As you will have seen, there are many security features provided by the CDS. Which options you choose will depend on the security requirements for your data and user access. You will not likely use all these features, but will be able to select the most appropriate features to meet your scenario.

Summary

In this chapter, we learned about the capabilities of the security model in the CDS, primarily business units and security roles. We also discussed alternative security approaches with teams, field security, and hierarchies. 

We covered how to add a user and then apply security features to the user to ensure they have access to the necessary data and functionalities to do their job.

You will now be able to identify the appropriate security features to meet your requirements, and then be able to configure environments and security settings as needed.

In the next chapter, we will introduce model-driven apps and how to build them, and in doing so we will compare them with canvas apps.

Questions

After reading this chapter, test your knowledge with these questions. You will find the answers to these questions under the Assessments section at the end of the book:

1. Your users report that they are not seeing your model-driven app. What should you do?

A) Share the app.
B) Publish the app.
C) Run the app checker.
D) Run the solution checker.

2. You have a business unit hierarchy. The user has been created in the root business unit and has been assigned a security role with Read Account set to Business Unit. Which accounts can they see?

A) Accounts they own
B) Accounts in their business unit
C) Accounts in their business unit and the child business units one level beneath it
D) Accounts in their business unit and all child business units beneath it

3. A user is assigned three security roles. The first security role has Read Account set to Parent: Child Business Units, the second security role has Read Account set to User, and the third security role has Read Account set to None. What is the effective access level on accounts for this user?

A) None
B) User
C) Business Unit
D) Parent: Child Business Units
E) Organization

4. You have created a new model-driven app. Your users are unable to see the app, but you can. What should you do?

A) In the app designer, run Validate.
B) In the app designer, click Publish.
C) Export the app and tell the users to import the app.
D) Share the app and select the appropriate security role.
E) Tell the users to use the classic interface.

5. You have assigned a user two security roles. The user's access level for a specific entity will do which of the following?

A) Reflect the most restrictive level of access for that entity across both security roles.
B) Reflect the highest level of access for that entity across both security roles.
C) Automatically default to read privileges for organization access.
D) Be determined by the user's field-level security profile.

6. Before a user can be assigned a security role, they must be assigned to which of the following?

A) A region
B) A business unit
C) An access team
D) A security group
E) A field security profile

7. Which of the following technologies is used as the primary authentication method for Dynamics 365?

A) Windows Hello
B) Azure Multi-Factor Authentication
C) Azure AD
D) Azure Conditional Access
E) Dynamics 365 security profiles

Further reading

Here are a few links if you wish to read more:

• Security in the CDS: https://docs.microsoft.com/power-platform/admin/wp-security
• Manage the encryption key: https://docs.microsoft.com/power-platform/admin/manage-encryption-key
• Manage teams: https://docs.microsoft.com//power-platform/admin/manage-teams
• User service admin roles to manage your tenant: https://docs.microsoft.com/power-platform/admin/use-service-admin-role-manage-tenant
• Share a model-driven app: https://docs.microsoft.com/powerapps/maker/model-driven-apps/share-model-driven-app
• System and application users: https://docs.microsoft.com/power-platform/admin/system-application-users
• Create a team template to control access rights for automatically created teams: https://docs.microsoft.com/power-platform/admin/create-team-template-add-entity-form
• Field-level security: https://docs.microsoft.com/power-platform/admin/field-level-security