Control data access
Applies To: Dynamics CRM 2013
To control data access, you must set up an organizational structure that both protects sensitive data and enables collaboration where appropriate. You do this by setting up business units, security roles, and field security profiles.
Business units
A business unit basically is a group of users. Large organizations with multiple customer bases often use multiple business units to control data access and define security roles so that users can access records only in their own business unit. More information: Create business units
Security roles
A security role defines how different users, such as salespeople, access different types of records. To control access to data, you can modify existing security roles, create new security roles, or change which security roles are assigned to each user. Each user can have multiple security roles.
Security role privileges are cumulative: having more than one security role gives a user every privilege available in every role.
Each security role consists of record-level privileges and task-based privileges.
Record-level privileges define which tasks a user with access to the record can do, such as Read, Create, Delete, Write, Assign, Share, Append, and Append To. Append means to attach another record, such as an activity or note, to a record. Append to means to be attached to a record.
Task-based privileges, at the bottom of the form, give a user privileges to perform specific tasks, such as publish articles or perform a mail merge.
The colored circles in the security role settings page define the access level for that privilege. Access levels determine how deep or high in the organizational business unit hierarchy the user can perform the specified privilege. The following table lists the levels of access in Microsoft Dynamics CRM, starting with the most access.
.jpeg "Global access level in Dynamics CRM")
|
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. |
.jpeg "Deep access level in Dynamics CRM")
|
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. |
.jpeg "Local access level in Dynamics CRM")
|
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. |
.jpeg "Basic access level in Dynamics CRM")
|
Basic. This access level gives a user access to records he or she owns, objects that are shared with the user, and objects that are shared with a team that the user is a member of. This is the typical level of access for sales and service representatives. The application refers to this access level as User. |
.jpeg "None access level in Dynamics CRM")
|
None. No access is allowed. |
Important
To ensure that users can view and access all areas of the web application, such as entity forms, the Navigation Pane, and the ribbon, all security roles in the organization must include the Read privilege on the Web Resource entity. For example, without read permissions, a user will not be able to open a form that contains a web resource and will see an error message similar to this: “Missing prvReadWebResource privilege.” For more information, see Create or edit a security role.
Overriding security roles
The owner of a record or a person who has the Share privilege on a record can share a record with other users or teams. Sharing can add Read, Write, Delete, Append, Assign, and Share privileges for specific records.
Teams are used primarily for sharing records that team members ordinarily couldn't access. For more information, see Manage security, users and teams.
It is not possible to remove access for a particular record. Any change to a security role privilege applies to all records of that record type.
Securing custom fields
In Microsoft Dynamics CRM, fields on forms can have read, create, and update permissions. Create or change custom field permissions using the Field Security setting on the field customization form and by establishing Field Security Profiles.
Field security profiles are similar to security roles in Microsoft Dynamics CRM. Both specify what users or groups of users can see, modify, or create in Microsoft Dynamics CRM.
When creating a custom field on a form, you have the option to use field security. Using field security for a field limits access to a field based on a user's field security profile. Not using field security for a field bases any restrictions to the field only on a user's security role.
See Also
Security concepts for Microsoft Dynamics CRM
Manage security, users and teams
Create or edit a security role
© 2016 Microsoft Corporation. All rights reserved. Copyright