Microsoft Dynamics security is an efficient security model which ensures data security/integrity in all Microsoft CRM applications. This security model was created with the following things in mind:
(a)It was supposed to act like a licensing model for all users
(b)Provide the access to the relevant data levels in regards to the user’s role
(c)Organize and categorize a user based on their role in an organization, so they are not able to gain access to other levels.
(d)To support data sharing so the relevant user can have access to items they would find useful in their specific collaborative efforts
(e)Finally, it was created with the aim of preventing the user from accessing items they don’t want to share, or those they don’t own.
In other words, this Microsoft dynamics security model will bring together all business units, role-based security, field-based security and data-based security to define the level of access that users will have in the overall Microsoft CRM organization.
Digging Deeper
1. Role-based Security
Each user or team of users has roles they should be performing in an organization. And in relation to this, they should only have access to data that concerns their role. This calls for a security model with the capability of grouping together sets of privileges related to specific tasks that a group of users must perform.
The good thing is that this model was designed with pre-designed security roles in place. These are sets of privileges which should only be used to make security management easier.
Again, the privilege can be set upon the ability to read data, write, edit, delete or even share that specific data with other users. These are parameters upon which the privileges should be set.
In every privilege, the person responsible will be told the extent to which a user can access it. For instance, we have basic user level, business unit, the whole business hierarchy and finally the entire company.
So if you’re signed in for a salesperson role, you will only have the privilege to read, write or even share accounts of the company in question. However, you are only allowed to delete account records you own.
Again, a salesperson doesn’t have the privilege of conducting system administrative tasks such as installing or conducting software updates, or even adding new users into the system.
On the other hand, if a user has been given the role of a Vice President for sales, they will have access to more features. They will have more privileges which are associated to viewing or even entering data and resources.
Therefore, this person can read, write or assign accounts to anyone within the organization.
Finally, it is worth noting that there are two more tiers in this system– created for two roles that have a greater number of privileges. These people are system administrators and customizers.
You see, in order to avoid running into problems associated with system misconfiguration, these roles must only be restricted to two people only. They will be responsible for administering and customizing the security model. What’s more, this model also allows companies to customize roles, or even create new roles that never existed in the system.
2. Record-based Security
This level can be used with the intent of controlling a user or a team’s rights to manipulate or perform some action on individual records. Again, the owner of a particular record can share, or grant access of the record to another member of the team. And when they perform this action, they must determine which rights are being granted and which ones should not be granted.
So for instance, a user who owns an account record can grant access to reading but not writing on that account. It’s important to note that access rights will only take effect after parameters have been set accordingly.
For example, if users don’t have access to read a particular account record, then they will not even access that account record in the first place. In fact, they might not even be able to view the account record even if a more privileged user granted them access to that account through sharing capabilities.
3. Business Unit
A group of users in an organization or company is referred to as a business unit. Larger businesses with multiple customer bases may use more than one business unit to control access to crucial data within the organization.
4. Hierarchy Security
This model is only used by people who want to access hierarchy data. This level contains more sensitive records, and is only used by managers to access records of approval or when they want to work on a particular record. It covers both manager hierarchies to position hierarchy within the company.
However, for a manager to be able to use his role here, they must be within the same business unit as the report they are trying to access. Alternatively, they must be in the parent business unit of the respective report’s business unit.
On the other hand, position hierarchy only deals with access of data across the business unit. So if this is a financial institution, you may opt for accessing Manager Hierarchy model, because this will prevent managers from accessing data from outside their respective business unit.
5. Field-based Security
This model is used when one wants to restrict access to some high impact business fields within the organization. Again, this model only takes effect after specific parameters have been set forth. So in as much as a user may be granted access to read an account, they may be prevented from reading certain sections of that account.
6. Deployment of Administrative-level security
During the installation of Microsoft dynamics security, the system will create a special administrator role – which is attached to the user’s account which is used to operate the Microsoft dynamics security server. Therefore, administrators who deploy this system have complete access to all levels of accounts within the organization.
Conclusion
It’s important to note that Microsoft does not view the job of a deployment administrator as a security role. For this reason, it won’t appear in the Microsoft Dynamic security system as much.
