When a user logs on to the system, Microsoft Dynamics CRM looks at the privileges of the user's assigned security roles and uses that information to determine what the software will allow the user to do and see throughout the system. This is known asrole-based security.
Each privilege within Microsoft Dynamics CRM also has associated with it a privilege depth. Whereas a privilege describes what actions can be taken in the system, a privilege depth indicates which specific objects that action can be taken on. Think of this as object-based security
Table 4-1. PrivilegeDepth Enumeration
Name
Value
Description
Basic
0
Grants user-level access. The user can only perform the privileged action on records he owns or records that are shared with him.
Local
1
Grants business-unit access. The user can only perform the privilege on records in his own business unit.
Deep
2
Grants parent and child business-unit access. The user can perform the privilege on records in her business unit or any business unit lower in the business unit hierarchy.
Global
3
Grants organization-level access. The user can perform the privilege on any record in the system.
2. Security Principals
Table 4-2. Security Principals
Name
Description
User
A user in the system who has assigned security roles that determine his or her access.
Team
Teams do not have security roles, but you can share objects. The actual access to the record is determined by the share privileges
3. Access Rights
Table 4-3. Common Actions and Required Access Rights
Action
Required Access Rights
Creating and owning an instance of an entity
Read, Create
Sharing an instance of an entity
Share (required by the user doing the sharing), Read (required by both the user doing the sharing and the user the instance is being shared with)