How role-based security can be used to control access to entities

In Dynamics 365 Customer Engagement (on-premises) the fundamental concept in role-based security is that a role contains privileges that define a set of actions that can be performed within the organization. For example, the salesperson role is assigned a set of privileges that are relevant to the performance of the tasks defined for that role. All users must be assigned to one or more predefined or custom roles. In Dynamics 365 Customer Engagement (on-premises), roles can also be assigned to teams. When a user or team is assigned to one of these roles, the person or team members are assigned the set of privileges associated with that role. A user must be assigned to at least one role.

A privilege authorizes the user to perform a specific action on a specific entity type. Privileges apply to an entire class of objects, rather than individual instances of objects. For example, if a user does not have the privilege to read accounts, any attempt by that user to read an account will fail. A privilege contains an access level that determines the levels within the organization to which a privilege applies. Each privilege can have up to four access levels: Basic, Local, Deep, and Global.

Roles

Dynamics 365 Customer Engagement (on-premises) includes fourteen predefined roles that reflect common user roles with access levels defined to match the security best-practice goal of providing access to the minimum amount of business data required for the job. With these roles you can quickly deploy a Dynamics 365 Customer Engagement (on-premises) system without having to define your own roles. However, you can create custom roles using the predefined roles as a template, or you can define a new set of roles. For a list, see List of Predefined Security Roles.

Each role is associated with a set of privileges that determines the user or team’s access to information within the company.

You can create roles within Dynamics 365 Customer Engagement (on-premises) and modify or remove these custom roles to fit your business needs. The roles you create for your business unit are inherited by all the business units in the hierarchy.

You can assign one or more roles to a user or to a team. For example, a user can have the Sales Manager role in addition to being a Customer Service Representative, in which case that user has all the privileges of both roles.

You cannot modify privileges at the user level, but you can create a new role with the desired privileges. For example, John is given a Salesperson role, which requires them to accept all leads assigned to them. However, the administrator wants John to be able to reassign leads assigned to John. As a result, the administrator either has to modify the Salesperson role to allow this or create a new role that incorporates this specific privilege and add John to this role. Creating a new role is the recommended option unless you think it necessary that all users who are assigned the Salesperson role now have this additional privilege.

Privileges

In Dynamics 365 Customer Engagement (on-premises), there are over 580 privileges that are predefined system-wide during setup. A privilege is a permission to perform an action in Dynamics 365 Customer Engagement (on-premises). Some privileges apply in general and some to a specific entity type.

Dynamics 365 Customer Engagement (on-premises) uses privileges as the core of the underlying security check. Privileges are "built in" to the product and are used throughout the application and platform layers. You cannot add or remove privileges, or change how privileges are used to grant access to certain functionality, but you can construct new roles from the existing privilege set.

Each role defines a set of privileges that determines the user or team's access to information within the company. The platform checks for the privilege and rejects the operation if the user does not have the necessary privilege. A privilege is combined with a depth or access level.

For example, the Salesperson role could contain the privileges Read Account with Basic access and Write Account with Basic access, whereas the Sales Manager role might contain privileges like Read Account with Local access and Assign Contact with Local access.

Most entities have a set of possible privileges that can be added to a role that correspond to the various actions you can take on the records of that entity time.

Each action in the system, and each message described in the SDK documentation, requires one or more privileges to be performed.

Access levels

The access level or privilege depth for a privilege determines, for a given entity type, at which levels within the organization hierarchy a user can act on that type of entity.

The following table lists the levels of access in Dynamics 365 Customer Engagement (on-premises), starting with the most access. The icon is shown in the security role editor in the Web application.

Access level	Description
	Global. This access level gives a user access to all records within the organization, regardless of the business unit hierarchical level to which the instance or the user belongs. Users who have Global access automatically have Deep, Local, and Basic access, also. Because this access level gives access to information throughout the organization, it should be restricted to match the organization's data security plan. This level of access is usually reserved for managers with authority over the organization. The application refers to this access level as Organization.
	Deep. This access level gives a user access to records in the user's business unit and all business units subordinate to the user's business unit. Users who have Deep access automatically have Local and Basic access, also. Because this access level gives access to information throughout the business unit and subordinate business units, it should be restricted to match the organization's data security plan. This level of access is usually reserved for managers with authority over the business units. The application refers to this access level as Parent: Child Business Units.
	Local. This access level gives a user access to records in the user's business unit. Users who have Local access automatically have Basic access, also. Because this access level gives access to information throughout the business unit, it should be restricted to match the organization's data security plan. This level of access is usually reserved for managers with authority over the business unit. The application refers to this access level as Business Unit.
	Basic. This access level gives a user access to records they own, objects that are shared with the user, and objects that are shared with a team of which the user is a member. This is the typical level of access for sales and service representatives. The application refers to this access level as User.
	None. No access is allowed.

Putting it all together

• If a user has the Deep Read Account privilege, this user can read all accounts in their business unit, and all accounts in any child business unit of that business unit.

• If a user has Local Read Account privileges, this user can read all accounts in the local business unit.

• If a user is assigned the Basic Read Account privilege, this user can read only the accounts that they own or the accounts that are shared with them.

• A customer service representative with the Basic Read Account privilege can view accounts that they own and any accounts another user has shared with this user. This makes it possible for the representative to read the account data that is relevant to a service request, but not to change the data.

• A data analyst with the Local Read Account privilege can view account data and run account-related reports for all accounts in their business unit.

• A finance officer for the company with the Deep Read Account privilege can view account data and run account-related reports for all accounts in their business unit and accounts in any child business unit.

List of predefined security roles

The following table lists the predefined set of roles that are included.

Role	Description
CEO-Business Manager	A user who manages the organization at the corporate business level.
CSR Manager	A user who manages customer service activities at the local or team level.
Customer Service Representative (CSR)	A customer service representative (CSR) at any level.
Delegate	A user who is allowed to act on behalf of another user.
Marketing Manager	A user who manages marketing activities at the local or team level.
Marketing Professional	A user engaged in marketing activities at any level.
Sales Manager	A user who manages sales activities at the local or team level.
Salesperson	A salesperson at any level.
Schedule Manager	A user who schedules appointments for services.
Scheduler	A user who manages services, required resources, and working hours.
Support User	A user who is a customer support engineer.
System Administrator	A user who defines and implements the process at any level.
System Customizer	A user who customizes Dynamics 365 for Customer Engagement entities, attributes, relationships, and forms.
Vice President of Marketing	A user who manages marketing activities at the business unit level.
Vice President of Sales	A user who manages the sales organization at the business unit level.

See also

The Security Model of Microsoft Dynamics 365 Customer Engagement (on-premises)
Privilege and Role Entities
Use record-based security to control access to records
How Field Security Can Be Used to Control Access to Field Values In Microsoft Dynamics 365 Customer Engagement (on-premises)