Security Model Building Blocks

In the previous step, we learned about security in both CDS and Dynamics 365. In this step, we will uncover the Security Model Building Blocks.

Teams

With the exception of records from Organisation owned entities, the owner field on a record can be populated with a User or Team record. When a record is owned by a Team, all of the members of the Team share ownership of the record from a security perspective. Just like Users, Teams rely on security roles and can own records, views, charts, and dashboards.

Business Units

Business Units provide security and structure for grouping users and are often used to mimic an organisation’s departmental structure. Every environment has a root business unit that cannot be deleted or moved. A hierarchy of additional child business units can be created as needed. A business unit only has one parent business unit but may have multiple child business units.

A user’s security roles are assigned within their business unit. If a user is moved to a different business unit, their security roles must be re-assigned. Each user is a member of only one business unit, but a team can have user members from multiple business units.

Security Roles

Every user must have at least one security role but may have multiple. A user’s effective security is the combination of all roles granted to that user. Security roles can be created from a copy of an existing role. A common practice is to copy from a system security role and then make modifications. Even though you are able, it is not recommended to edit out of the box roles. It is best to leave these as they were originally and save a copy of the role to configure to meet your needs. As the application is upgraded, the system security roles will be updated to support new features, modifying these system security roles may cause problems in the future. Security roles are portable between environments when placed in Solutions.

A security role is a collection of record-level privileges set at an access level. Record level privileges control a user’s ability to Create, Read, Write, Delete, Append, Append To, Assign and Share a record. The access level for each of these privileges determines the group of records where the user can perform that action. Access levels for User or Team owned entities are granted at four levels: User, Business Unit, Parent: Child Business Units, and Organisation. Access levels for Organisation owned entities can only be granted at an Organisation level or no access.

The User level grants the privilege for records owned by the user or a team in which the user is a member. The Business Unit level extends the privilege beyond User to include records within the user’s Business Unit. The Parent: Child Business Unit level is an expansion of Business Unit level access which includes Business Units which are a child Unit of the user’s Business Unit. Organisation level security allows the privilege on every record within that entity, regardless of ownership or Business Unit.

Field Level Security

An additional layer of security can be applied as Field Level Security. Once field-level security is applied to a field, only users with a corresponding Field Security Profile will be able to view or update the data within the field, depending on the privilege granted.

Field Security Profiles are portable between environments when placed in Solutions.

Access Teams

Access Teams and Team Templates provide flexibility to the users for creating ad-hoc security on a specific record as needed. For example, you may use an Access Team on the Account entity to allow users to add a member to the Sales Team to give that member the Read and Write permissions on that specific Account record.

Hierarchy Security

Hierarchies can be added to accommodate complex reporting structures where security must be granular beyond business units or where a management structure may operate outside of the business unit structure. Depth can be used to grant management read-only access to records owned by users who are not their direct reports and within the specified number of levels of hierarchy beneath the manager.

Manager Hierarchies follow a direct reporting structure by utilising the Manager field on the user record and can only be used when the manager and the reporting user are located within the same business unit.

Positional Hierarchies are not tied to a reporting structure and rely on a user’s position to determine where that user falls in the hierarchy. These hierarchies are not dependent on the business unit structure.

Data Loss Prevention Policies

Data Loss Prevention (DLP) Policies are an optional layer of security to control how data from applications may be used within PowerApps and Flow. These policies are managed in the Data Policies area of the PowerApps admin centre. Policies can apply to all environments or selected environments. When a policy is in effect PowerApps and Flows can only be created using data connectors either entirely from the Business Data Only section or the No Business Data Allowed (Default) section.

Changes

Keep in mind that Microsoft is constantly evolving the software that these courses are based on. You may find there is a difference between what is covered and what you experience. The intention is that there will be enough information to guide you.

For details and the latest changes, please access Microsoft Documentation site: Microsoft Dynamics 365 documentation

Next up, let’s discuss User Management Basics.