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.
|Create||Allows the user to add a new record.|
|Read||Allows the user to view a record.|
|Update||Allows the user to edit an existing record.|
|Delete||Allows the user to delete an existing record.|
|Assign||Allows the user to change the owner of the record, to another user or team.|
|Share||Allows the user to share an existing record. When sharing a record, it is possible to specify the permission given to the user.|
|Append||Allows 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 to||Allows 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.
Determine the scopes a user can perform a given privilege on data.
|None||No privilege was given. Set by default if nothing specified.|
|User||Privileges 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 Unit||Privileges for all records owned in the business unit to which the user belongs|
|Parent-Child Business Units||Privileges 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|
|Organization||Privileges 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:
- Privilege: Assign and Share privileges are not available.
- Access Levels: There are only two scopes available: None and Organization.
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.