Security concepts for Microsoft Dynamics CRM
Applies To: CRM 2015 on-prem, CRM Online
You use the security model in Microsoft Dynamics CRM to protect the data integrity and privacy in a Microsoft Dynamics CRM organization. The security model also promotes efficient data access and collaboration. The goals of the model are as follows:
Provide a multi-tiered licensing model for users.
Grant users access that allows only the levels of information required to do their jobs.
Categorize users and teams by security role and restrict access based on those roles.
Support data sharing so that users can be granted access to objects they do not own for a one-time collaborative effort.
Prevent access to objects a user does not own or share.
You combine business units, role-based security, record-based security, and field-based security to define the overall access to information that users have in your Microsoft Dynamics CRM organization.
For more information about security topics, see the Microsoft Dynamics CRM SDK topic, The Security Model of Microsoft Dynamics CRM.
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 or edit business units
You can use to group sets of privileges together into roles that describe the tasks that can be performed by a user or team. Microsoft Dynamics CRM includes a set of predefined security roles, each of which is a set of privileges aggregated to make security management easier. The bulk of the privileges define the ability to create, read, write, delete and share records of a specific entity type. Each privilege also defines how broadly the privilege applies: at the user level, business unit level, the entire business unit hierarchy or across the entire organization.
For example, if you sign in as a user that is assigned the Salesperson role, you have the privileges to read, write and share accounts for the entire organization, but you can only delete account records that you own. Also, you have no privileges to perform system administration tasks such as install product updates, or to add users to the system.
A user that has been assigned the Vice President of Sales role can perform a wider set of tasks (and has a greater number of privileges) associated with viewing and modifying data and resources than can a user who has been assigned to the Salesperson role. A user assigned the Vice President of Sales role can, for instance, read and assign any account to anyone in the system, while a user assigned the Salesperson role cannot.
There are two roles that have very broad privileges: System Administrator and Customizer. To minimize misconfiguration, the use of these two roles should be limited to a few people in your organization responsible for administering and customizing Microsoft Dynamics CRM. Organizations can also customize existing roles and create its own roles to meet their needs.
You can use record-based security to control user and team rights to perform actions on individual records. This applies to instances of entities (records) and is provided by access rights. The owner of a record can share, or grant access to a record to another user or team. When this is done, they must choose which rights they are granting. For example, the owner of an account record can grant read access to that account information, but not grant write access.
Access rights apply only after privileges have taken effect. For example, if a user does not have the privileges to view (read) account records, they will be unable to view any account, regardless of the access rights another user might grant them to a specific account through sharing.
You can use the hierarchy security model for accessing hierarchical data. With this additional security, you gain a more granular access to records, allowing managers to access the records of their reports for approval or do work on reports’ behalf. More information: Hierarchy security
You can use field-level security to restrict access to specific high business impact fields in an entity only to specified users or teams. Like record-based security, this applies after privileges have taken affect. For example, a user may have privileges to read an account, but can be restricted from seeing specific fields in all accounts. More information: Field level security
During installation, Microsoft Dynamics CRM Server Setup creates a special deployment-wide administrator role and attaches it to the user account that is used to run Microsoft Dynamics CRM Server Setup. Deployment Administrators have complete and unrestricted access to all organizations in Deployment Manager in the Microsoft Dynamics CRM (on-premises) deployment. The Deployment Administrator role is not a security role and does not appear in the Microsoft Dynamics CRM web application as such.
Deployment Administrators can create new organizations or disable any existing organization in the deployment. Conversely, members of the System Administrator Role only have permissions within the organization where the user and security role are located.
|When a deployment administrator creates an organization, that administrator must give db_owner privileges for the org’s databases to the other deployment administrators so that they also have full access to those organizations.|
For more information about the Deployment Administrator role, see the Deployment Manager Help.
ConceptsAdministration best practices for on-premises deployments of Microsoft Dynamics CRM
Field level security
Create or edit a security role
Copy a security role
Add teams or users to a field security profile
Invite someone to use Microsoft Dynamics CRM
Other ResourcesManage security, users and teams
Scalable Security Modeling with Microsoft Dynamics CRM 2011
Send comments about this article to Microsoft.
© 2014 Microsoft Corporation. All rights reserved.