Privileges, Access Level & Ownership in Dynamics CRM

Privileges

Privileges enable users to take actions on records. They are the basic security unit that details what actions a user can perform in the CRM. Allow users to take actions on records.

CreateAllows the user to add a new record.
ReadAllows the user to view a record.
UpdateAllows the user to edit an existing record.
DeleteAllows the user to delete an existing record.
AssignAllows the user to change the owner of the record, to another user or team.
ShareAllows the user to share an existing record. When sharing a record, it is possible to specify the permission given to the user.
AppendAllows the user to attach other entities to or associate other entities with a parent record (e.g.: lookup fields). In case of many-to-many relationships, you must have Append privilege for both entities being associated or disassociated. In one line: when an entity has the lookup of another entity on its form.
Append toAllows the user to attach other entities to or associate other entities with the record. In one line: when an entity is available as a lookup on another entity form.

The above highlighted privileges are called “record-level privileges”. They defined which actions a user can do. There are also “task-based privileges”. Those miscellaneous privileges are not linked to an entity directly but operate on specific tasks, such as viewing audit history, publish e-mails, bulk edit, export data to Excel, etc.…
In Dynamics 365, task-based privileges are at the bottom of the Security Role form.

Note that it is not possible to remove access for a given record. Any change to a security role privilege applies to all records of that record type – exception made if the user has been given access to a record via the “Share” functionality.

Access Levels

Determine the scopes a user can perform a given privilege on data.

  NoneNo privilege was given. Set by default if nothing specified.
UserPrivileges to the records owned by the sure or share with the users. It also includes the privileges owned by the team user belongs to.
Business UnitPrivileges for all records owned in the business unit to which the user belongs
Parent-Child Business UnitsPrivileges for all records owned in the business unit to which the user belongs and to all the child business units subordinate to that business unit
  OrganizationPrivileges for all records in Dynamics 365.

In Dynamics 365, this is indicated by the degree of fill and color of the little circles against each entity for each privilege.

Entity Ownership: When creating an entity, administrators need to specify the kind of ownership between “User or Teams” and “Organization”. By default, the value is set to “User or Teams”.

If “Organization” is chosen, it will have an impact on the Privileges and Access levels available. As the entity is owned by the organization, there is no specific owner and no notion of Business Unit ownership.

Therefore, in the Security Roles for those entities:

  • PrivilegeAssign and Share privileges are not available.
  • Access Levels: There are only two scopes available: None and Organization.

Business Unit

Dynamics 365 uses Business Units to differentiate different parts of a company that might have different security needs. As such, they are a basic component of the security in Dynamics 365.
A Business Unit is composed of users, teams, and security roles. A user part of a business unit can only be assigned security roles belonging to this business unit.


Each Dynamics 365 CRM has a root business unit created by default. It cannot be deleted nor disabled, but it can be renamed. All other business units created by system administrators will be a child of the root business unit.

Business units are useful if the company segregates its business and needs to have different data access for each subsidiary. If there is no need to segregate data between subsidiaries, divisions, or departments then there will only be the one business unit.

Duplicate Detection & Merging in Dynamics CRM:

If we enable duplicate detection rules then we can set it either to not allow duplicates or allow but only prompt of duplication.

If any duplicate records detected system will prompt as per below snapshot. user can click on Ignore and Save to continue saving the record.

Merging:

If user wish to merge the record need to select more than 1 record to enable the Merge button.

user can select primary record with which other record will be merged as per below snapshot.

When user clicks on OK the record will be merged Primary record will be retained whereas secondary record will be deactivated.