Privileges by Entity
[Applies to: Microsoft Dynamics CRM 4.0]
Find the latest SDK documentation: CRM 2015 SDK
Microsoft Dynamics CRM ships with a set of thirteen 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. You can also create custom roles. Each role is associated with a set of privileges that determines the user's access to information within the company. These privileges determine what actions a user with that security role can perform on entities. For more information see the Role-Based Security and Object-Based Security.
Microsoft Dynamics CRM includes the privileges, listed in the following table, that apply to most entity types.
|Create||Create an entity.|
|Write||Make changes to entities for users.|
|Delete||Remove entities for users.|
|Append||Associate a selected entity to another entity.|
|Append To||To associate an entity to this entity.|
|Assign||Give access to entities to another user.|
|Share||Give access to entities to another user while keeping your own access.|
|Reparent||Assign a different parent to an entity.|
|Enable/Disable||Give or take away privileges.|
Privilege levels for the same security role in a different business unit can be set at different levels. For example, a security role can have parent-child level access for a sales department, and organization-wide access for an accounting department. Privileges at a lower-level business unit cannot be lower than that of the main or primary business unit. However, the privileges at the lower-level business unit can be higher than that of the main or primary unit. Sometimes, you might need to create a custom role to permit the different privilege levels.
With your privileges set, you can perform actions on records. However, access levels determine on which specific records you can perform those actions. For more information see Access Levels.
The following table describes the supported access levels.
|Symbol||SDK Name||Application Name||Description|
|Global||Organization||This global access level lets the user work with all record types within the entire organization, regardless of the business unit hierarchical level to which the entity or user belongs. Users who have Organization access automatically have Parent: Child Business Units, Business Unit, and User access as well.|
|Deep||Parent: Child Business Units||This deep access level lets the user work with record types in the user's business unit, and all business units subordinate to the user's business unit. Users with Parent: Child Business Units access automatically have Business Unit and User access as well. For example, if a user has Parent: Child Business Units Read Account privileges, the user can read all accounts in his or her business unit, as well as all accounts in any child business unit of that business unit.|
|Local||Business Unit||This middle access level lets the user work with record types in the user's business unit. Users who have Business Unit access automatically have User access as well. For example, if a user has Business Unit Read Account privileges, the user can read all accounts in the local business unit.|
|Basic||User||This entry access level lets the user work with record types they own, record types that are shared with the user, and record types that are shared with the team of which the user is a member. For example, if a user is assigned the User Read Account privilege, the only accounts that can be read are those that are owned by or shared to the user.|
|None||None Selected||This access level denies the user privileges at any level. A privilege is not added to the security role.|
The following table lists the entities. Click the entity to go to the topic that lists the privileges for the entity.