Role-Based Security

Role-Based Security

The fundamental concept in role-based security is that privileges are assigned to defined categories of users (known as roles) rather than to individual users. When a user is assigned to one of these roles, he or she is assigned the set of privileges associated with that role. A user who is not assigned to a role does not have any privileges.

In Microsoft Dynamics CRM, a role describes a defined set of responsibilities (or tasks to perform) within the organization. A role, for example, a salesperson, 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 of these predefined roles.

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.

The access level 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

Roles

Microsoft Dynamics CRM 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 Microsoft Dynamics CRM 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 of these predefined roles, see Appendix A: Security Roles and Privileges.

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

You can create roles within Microsoft Dynamics CRM 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. 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 him to accept all leads assigned to him. However, the administrator wants John to be able to reassign leads assigned to him. 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

Privileges

In Microsoft Dynamics CRM, there are over 480 privileges that are predefined system-wide during setup. A privilege is a permission to perform an action in Microsoft Dynamics CRM system on a specific entity type. For a complete list of the privileges available in Microsoft Dynamics CRM, see Privileges by Entity.

Microsoft Dynamics CRM 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's access to information within the company. The platform checks for the privilege and rejects the operation if the user does have the necessary privilege. A privilege is combined with a depth or access level.

For example, the Salesperson role could contain the privileges prvReadAccount with Basic access and prvWriteAccount with Basic access, whereas the Sales Manager role might contain privileges like prvReadAccount with Local access or prvAssignContact with Local access.

 

Access Levels

Access Levels

The access level 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. Microsoft Dynamics CRM has the levels of access shown in the following table, starting with the most access.

	Global. This access level exposes to a user all entity instances 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. Note   The application refers to this access level as Organization.
	Deep. This access level exposes to a user entity instances 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. Note   The application refers to this access level as Parent: Child Business Units.
	Local. This access level exposes to a user entity instances 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. Note   The application refers to this access level as Business Unit.
	Basic. This access level exposes to a user entity instances he or she owns, 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. Note   The application refers to this access level as User.
	None Selected. None.

Examples

• If a user has Deep Read Account privileges, this user can read all accounts in his or her 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 he or she owns or the accounts that are shared with him or her.
• A customer service representative with the Basic Read Account privilege can view accounts that he or she owns 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 his or her 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 his or her business unit and accounts in any child business unit.