Microsoft Dynamics 365 and Microsoft Dynamics 365 (online) provide a security model that protects data integrity and privacy, and supports efficient data access and collaboration.
The goals of the model are as follows:
- Provide users with the access only to the appropriate levels of information that is required to do their jobs.
- Categorize users by role and restrict access based on those roles.
- Support data sharing so that users and teams can be granted access to records that they do not own for a specified collaborative effort.
- Prevent a user’s access to records the user does not own or share.
Role Based Security: focuses on grouping a set of privileges together that describe the responsibility for a user.
Record Based Security: Focuses on access rights to specific records
Field Level Security: Restrict access to specific high business impact fields in an entity only to specified user or teams.
Hierarchy Security: Enables you to model the manager/direct report structure that is often used in businesses. The Position entity provides the capability to model this type of relationship. A system user in a higher-level position can access the business data being accessed by another user in a lower level position.
Role based security can be used to control access to entities
Role contains privilege that defines a set of actions that can be performed within the organization. All users must be assigned to one or more predefined or custom roles. Roles can also be assigned to teams. When a user or team is assigned to one of these roles, the person or team members are assigned the set of privileges associated with that role. A user must be assigned to at least one role. Microsoft Dynamics 365 includes 14 predefined roles.
A privilege authorizes the user to perform a specific action on a specific entity type. In Microsoft Dynamics 365, there are over 580 privileges that are predefined system-wide during setup. Privileges apply to an entire class of objects, rather than individual instances of objects. A privilege contains an access level that determines the levels within the organization to which a privilege applies. Each privilege can have up to four access levels: Basic, Local, Deep, and Global.
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. The application refers to this access level as Organization.
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. The application refers to this access level as Parent: Child Business Units.
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. The application refers to this access level as Business Unit.
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 of which the user is a member. The application refers to this access level as User.
None. No access is allowed.
Putting it all together
- If a user has the Deep Read Account privilege, this user can read all accounts in his or her business unit, and all accounts in any child business unit of that business unit.
- If a user has Local Read Account privileges, this user can read all accounts in the local business unit.
- If a user is assigned the Basic Read Account privilege, this user can read only the accounts that he or she owns or the accounts that are shared with him or her.
- A customer service representative with the Basic Read Account privilege can view accounts that he or she owns and any accounts another user has shared with this user. This makes it possible for the representative to read the account data that is relevant to a service request, but not to change the data.
- A data analyst with the Local Read Account privilege can view account data and run account-related reports for all accounts in his or her business unit.
- A finance officer for the company with the Deep Read Account privilege can view account data and run account-related reports for all accounts in his or her business unit and accounts in any child business unit.
List of predefined security roles
||A user who manages the organization at the corporate business level.
||A user who manages customer service activities at the local or team level.
|Customer Service Representative (CSR)
||A customer service representative (CSR) at any level.
||A user who is allowed to act on behalf of another user.
||A user who manages marketing activities at the local or team level.
||A user engaged in marketing activities at any level.
||A user who manages sales activities at the local or team level.
||A salesperson at any level.
||A user who schedules appointments for services.
||A user who manages services, required resources, and working hours.
||A user who is a customer support engineer.
||A user who defines and implements the process at any level.
||A user who customizes Microsoft Dynamics 365 entities, attributes, relationships, and forms.
|Vice President of Marketing
||A user who manages marketing activities at the business unit level.
|Vice President of Sales
||A user who manages the sales organization at the business unit level.
Record Based Security:
It applies to individual records. It is provided by using access rights. The relationship between an access right and a privilege is that access rights apply only after privileges have taken effect.
An access right is granted to a user for a particular record.
Read: Controls whether the user can read a record.
Write: Controls whether the user can update a record.
Assign: Controls whether the user can assign a record to another user.
Append: Controls whether the user can attach another record to the specified record.
The Append and Append To access rights work in combination. Every time that a user attaches one record to another, the user must have both rights. For example, when you attach a note to a case, you must have the Append access right on the note and the Append To access right on the case for the operation to work.
Append To: Controls whether the user can append the record in question to another record.
Share: Controls whether the user can share a record with another user or team. Sharing gives another user access to a record. For more information, see Sharing records.
Delete: Controls whether the user can delete a record.
Create access: The right to create a record for an entity type is not included in the previous table because this right does not apply to an individual record, but instead to a class of entities. Create is handled as a privilege instead of as an access right. The user who creates a record has all rights on that record, unless his or her other privileges forbid a specific right.
Sharing records: Sharing lets users give other users or teams access to specific customer information. This is useful for sharing information with users in roles that have only the Basic access level. For example, in an organization that gives salespeople Basic read and write access to accounts, a salesperson can share an opportunity with another salesperson so that they can both track the progress of an important sale.
Share. Any user who has share privileges on a given entity type can share records of that type with any other user or team.
Sharing and inheritance: If a record is created and the parent record has certain sharing properties, the new record inherits those properties. For example, Joe and Mike are working on a high priority lead. Joe creates a new lead and two activities, shares the lead with Mike, and selects cascade sharing. Mike makes a telephone call and sends an email regarding the new lead. Joe sees that Mike has contacted the company two times, so he does not make another call.
Sharing is maintained on individual records. A record inherits the sharing properties from its parent and also maintains its own sharing properties. Therefore, a record can have two sets of sharing properties—one that it has on its own and one that it inherits from its parent.
Removing the share of a parent record removes the sharing properties of objects (records) that it inherited from the parent. That is, all users who previously had visibility into this record no longer have visibility. Child objects still could be shared to some of these users if they were shared individually, not from the parent record.
Assigning records: Anyone with Assign privileges on a record can assign that record to another user. When a record is assigned, the new user or team becomes the owner of the record and its related records. The original user or team loses ownership of the record, but automatically shares it with the new owner.
Used to restrict access to high business impact fields to specific users and teams. For example, you use this to enable only certain users to read or update the credit score for a customer. For this release, field-level security can be applied to both custom fields and many out-of-box (OOB) fields.
The following steps describe how to restrict access to a field:
- Enable field-level security for an attribute
- Create a field-level security profile
- Associate users or teams with the profile
- Add specific field permissions, such as Create, Update or Read for a specific attribute to the profile
Role-based security lets you see a specific entity type, record-based security lets you see individual records, and field-level security lets you see specific fields.
Hierarchy Security Model: The hierarchy security model is an extension to the existing Microsoft Dynamics 365 security models that use business units, security roles, sharing, and teams. It can be used in conjunction with all other existing security models. The hierarchy security offers a more granular access to records for an organization and helps to bring the maintenance costs down. For example, in complex scenarios, you can start with creating several business units and then add the hierarchy security. This will achieve a more granular access to data with far less maintenance costs that a large number of business units may require.