Overview
To control data access, you must set up an organizational structure that both protects sensitive data and enables collaboration. You do this by setting up business units, security roles, and field security profiles.
The diagram below represents all the components that impact how a user can have access to records and capabilities in Customer Engagement. This post specifically focuses on business units.
In Dynamics 365
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.
A user can have more than one security role. In this scenario the privileges cumulate.
Customer engagement security model is based on Record-level privileges. By entity we can define which tasks a user with access to the record can do – Read, Create, Delete, Write, Assign, Share, Append and Append To.
Append means to associate the current record with another record, such as attaching a note to an opportunity. The user would need append rights on the note. Append to means to associate a record with the current record. If a user has Append To rights on an opportunity, the user can add a not to the opportunity. Your consultant will be able to work out what is required here between entities. The most important information to give your implementing partner is the Create, read, write and delete rules.
In customer engagement a coloured circle is used to define the security role access level.
Organisation. Access level gives a user access to all records in the organisation, regardless of the business unit hierarchy.
Parent: Child Business Unit. Gives a user access to records in their users business unit and all subordinate business units.
Business Unit. This access level gives a user access to records in the user’s business unit.
User. This access level gives a user access to records that the user owns, objects that are shared with the organization, objects that are shared with the user, and objects that are shared with a team that the user is a member of.
None. No access is allowed
Example
The following is an example of an OOTB security role for Sales Manager
Compare this setup to the Salesperson account level access.
This example is showing the scenario where Sales Managers are able to create and delete records on behalf of themselves and their entire team/business unit. In addition they are able to change the assigned ownership of an account record to anyone in the business unit. The individual salesperson can only create records for themselves, only delete their own records and only change the assignment on records they already own.
Microsoft
See https://docs.microsoft.com/en-us/power-platform/admin/security-roles-privileges