Tech N Toast®

Security Model in Microsoft Dynamics 365 CRM

Security Model in Microsoft Dynamics 365 CRM

Protecting our data and privacy. All users efficiently access the important information while ensuring proper security and integrity because the security model controls authorized and unauthorized access. If you are not authorized to view something, you won't be able to do so.

You can view only that level of information, which is required to perform your tasks.

By default, a new crm user has read and write access.

You are working in a sales team, where you want to see sales records to do your job. Even, in this case you can not get all the information (deep and confidential). If you are an executive in the sales team, you can view only executive level items. If you are a sales manager, you can retrieve only those records, which are required to do your job. You are not authorized to examine something like Cases. Everything is determined by the security model.

My book - The security model of Microsoft Dynamics CRM

For example, you are a normal user. You want to customize CRM to add some more features. You need to call the system customizers or the system administrators because such tasks can only be performed by them.

Unauthorized data sharing is prohibited, but authorized data sharing arrangements are encouraged by the security model. Teams and users can share and view the shared items. CRM users cannot edit the shared records until they are given certain level of privileges. If they have read access, they can just read. They cannot write or edit. This is useful when different teams are working on one project, where they need to view some important information. The record owner can share it without any worries because they are aware that only read access being provided to the teams.   

Role-based, record-level, and field-level security in Microsoft Dynamics 365 CRM. 

Security Model in Microsoft Dynamics 365

Role-based security - There are some predefined security roles. Lots of privileges that make you able to create, read, write, delete, and share records. It also determines the level of access, which can be a basic user level, business unit, or organizational access rights (least restrictive). 

If you have got the customer representative role, you can read, write and share the accounts that you own, but you cannot assign or modify the data that is not in your bucket. On the other hand, if you have got the Customer Service manager role. You have got many privileges like viewing more information, assigning accounts, modifying records etc.

System Administrator and customizer are the two most powerful roles because they can customize the existing ones, and can create some more security roles. Such powers should be limited to a few people.

Record-level security - It defines your access rights to some specific things. If you are the owner of the records that you want to share with another user or team, choose which right you want to grant - Read or Write. 

Access rights are useful if you already have the required privileges. For example, the owner of the records wants to grant you the read access. You should already have the privileges to read. If don't have, you would not be able to view or read them.

Field-level security - A CRM user will have privileges to read an account, but can be restricted from seeing confidential and sensitive information. This feature does not allow everybody to see some important fields like bank account no. or other personal details. For example, you have a huge customer database, and there are some fields carrying important customer details that you don't want to be exposed to sales team while working on the same customer accounts. You can prevent the team from accessing such important details by implementing field-level security. 

Hierarchy security - Managers can read and update their team members’ records in the same business unit without seeing the data of other managers’ teams. This feature gives read access to the managers above the direct manager to view their team members' activities.

Business unit - A group of users. There can be one or two or three or more units, completely depends upon your organizational structure. Employees can view only that data, available in their own business unit, defined by their security roles.

Teams - Multiple teams work in one CRM organization. They share workloads, important details, accounts etc. to complete different projects. There can be many teams in one business unit or just one team. Again, it is your choice. Then, users in one team, can be from different business units or from the same unit the team belongs to. CRM users can be associated with more than one team.  


Security Roles - There are a set of privileges and access levels associated with your security role. Some important ones are -

System Administrator - A super user, can do anything. This person can create and remove administrators, customizers, users etc. 

System Customizer - Similar to the system administrator role, which is used to customize Dynamics 365 CRM.

Other roles - Customer service manager, CEO, marketing manager, sales manager, salesperson etc. are assigned to a user.


Privileges - What actions a CRM user can perform. Some common ones are - 

    Create - you can create or add a new record.

    Read - read or view.

    Write - write or edit.

    Delete - delete a record.

    Assign - you can assign ownership of a record to someone else.

    Share - you can share records.

    Append - attach other entities to a record. 

    Append to - attach other entities with a record.

'Append' and 'Append to' privileges work together - For example, two custom entities - 1. Apple and 2. Banana. Now, you want to attach the 'Banana' records to 'Apple' records. You should have 'Append' access right on 'Apple' entity and 'Append to' access right on 'Banana'. Please create a 1:N relationship between 'Apple' and 'Banana' to attach the records.


Levels of Access - Let's understand -

None - no privileges.

User - basic.

Business Unit - big privileges. You can see everything in that unit.

Parent: Child - bigger. Privileges to the records owned by the parent business unit, and the child business units associated to that parent unit.

Organization - biggest privileges. View everything in your organization. No restrictions.



No comments:
Post a Comment