• A Business unit is all or part of an organization.
• A security role is a collection of privileges and access levels.
• An entity is a collection of records, such as a sales deal, or prospect.
• Privileges allow users in a role to take actions on records in an entity.
• Access levels determine the scope of entities and records a user can take actions on, from most restrictive to least restrictive.

Every user must:

• Be assigned to just one business unit.
• Have at least one security role to be able to log in.

Users can have more than one security role. If they do, the role with the broadest permissions will override roles with lesser permissions.

Role-based security

Roles are groups of permissions that you can assign to a user to grant them access and various capabilities. Depending on their role, a user may be read only, or have full access to read, edit and delete records in an entity within an application. They are granular and can be assigned to one or many entities. Additionally, users are associated with one or many roles, and associating a user with a role gives them access to data and functionality that is specified within that role.

Predefined roles

Dynamics 365 includes many predefined security roles, each of which is a set of privileges aggregated to make security management easier. The bulk of the privileges define the ability to create, read, write, delete and share records of a specific entity type. Each privilege also defines how broadly the privilege applies: at the user level, business unit level, the entire business unit hierarchy or across the entire organization. However, you can also edit them or create new roles if needed.

Teams

Teams are security roles that cross business units, providing the same permissions and access to users in different organizations. Teams are typically used to allow users in different business units all work with the same entity such as a large customer.

Hierarchy security

You can use the hierarchy security model for accessing data based on the user’s position in the company hierarchy. With this additional security, you gain a more granular access to records. For example, Hierarchical security could allow managers to access the records of their reports for approval or to work with their reports on the records.

Record-based security

You can use record-based security to control user and team rights to perform actions on individual records. This applies to instances of entities (records) and is provided by access rights. The owner of a record can either share or grant access to a record to another user or team. When this is done, they must choose which rights they are granting. For example, the owner of an account record can grant read access to that account information, but not grant write access.

Access rights apply only after privileges have taken effect. For example, if a user does not have the privileges to view (read) account records, they will be unable to view any account, regardless of the access rights another user might grant them to a specific account through sharing.

Record-level privileges

Power Apps and model-driven apps use different record-level privileges that determine the level of access a user has to a specific record or record type.

Field-based security

You can use field-level security to restrict access to specific high business impact fields in an entity only to specified users or teams. Like record-based security, this applies after privileges have taken affect. For example, a user may have privileges to read an account, but can be restricted from seeing specific fields in all accounts.

If more granular control is needed for a particular field of data field level security can be configured. Administrators can identify the field(s) needing additional protection and effective mask the data contained in the field. The field will still be visible on the form record, however the data contained will only be visible to those users explicitly given access using field level security profiles. Most system fields, and all custom fields can be secured using field level security.

Security is enforced for the user across the application. If a user does not have access to an entity, they will not be able to see those records in a grid view, a chart, a report, a related record or in an Advanced Find query.

The same applies for data secured with field level security. If entity permission is set to restrict based on record ownership or business unit, then a user may see aggregate data in a report or dashboard, but will not be able to drilldown into detailed records that define the aggregate data.

Each application comes with several predefined security roles. If these roles do not meet your needs, you may customize them. You can also make entirely custom security roles. It is considered a best practice to copy a system role before customizing it leaving the predefined role intact and creating a new custom one for your needs.

Task-based privileges

In addition to record level privileges, security roles contain various task-based privileges that users can perform. In general, these privileges are on or off and not based on business unit or other organizational considerations.

User experience

A user’s experience in the application is the combined result of their defined security roles and team memberships as well as app licenses. Using security roles to limit a user’s access to records can improve their in-app experience by removing clutter that is not part of their requirements.

Users are granted access and privileges at the entity level. Access to individual records cannot be specifically granted. If the user’s combined roles do not allow access to a record, or the ability to perform actions with the record (such as read, write, append, etc.) then the user cannot work with the records outside of the scope of their defined roles. All application users need at least one security role assigned to access the application, a role assigned either to their user, or by their team membership.

The following graphic shows the security roles for a Salesperson.

 

Assigning or Removing Security Roles

1. Login to admin.powerplatform.microsoft.com

2. Select Environments and then select the correct environment

3. Under Users, select See all 

4. Click the circle next to the user's name and select Manage security roles 

5. Check the desired roles. Save 

Note: The below Security Roles should always be checked

-Salentica Address Management User Role

-Salentica CRM Plus Core User

-Salentica Skyline User

-Salentica Standard Role

Assigning Multiple Security Roles to Multiple Users

Note: Only users within the same Business Unit can be assigned multiple security roles at the same time.

 

1. Click on the gear icon (top right) and click Advanced Settings

2. Navigate to Settings>System>Security

3. Select Users

4. From the list, select the users you want to assign a security role to

5. Select Manage Roles

Note: Only the security roles available for the user's business unit are displayed.

   6. In the Manage User Roles dialog box, select the security role or roles you want for the users, and then select OK

 

---

Video: Security Roles