Dynamics CRM 2013 offers so many features and different ways to get users what they need. In some cases, this can be too much access (or even too overwhelming!) for users in organizations. We’ll talk about Entity and Record visibility or editing later- but there are great options built in to CRM that are very helpful, but not always right for every user to have access to.
Some of the common functionality that may need to be restricted for users may include:
- Deleting Records
- Editing Records
- View Audit History where enabled
- Bulk Edit
- Export to Excel
- Override Pricing
- Merge Records
These options show up in CRM in many places. When first configuring CRM it’s really important to understand that CRM knows it’s important to have the ability to customize User Access. But all too often the conversation around configuring security, or understanding these options comes late in the game. Understanding best practice around security saves a lot of time and headache in the long run.
If we want to restrict the ability of users to be able to delete records- what first pops into your head? “get rid of the delete button so no one can click it”. Yes, that’s generally a good thought. CRM accounts for you being able to do this by security role that gets applied to a user. We won’t go through the entire A-Z Security Roles just yet, but the quick version is that there are different levels and for every access option in CRM, you can have a corresponding user role, as needed.
The functions we talked about before exist in the Security Role area of CRM (Settings/ Administration/ Security Roles).
When you first open a Security Role, the options regarding entities show predominately and are usually focused on first. Look familiar?
A great rule for someone managing security in CRM is to look at the options in the Security Role area to understand at a basic level what can and cannot be done, before requesting code to make changes to Ribbon Bars, Site Maps, etc. Part of this involves looking further at Miscellaneous Privileges under the break. There are some cool restrictions available here. Some also may not make sense at first glance, but generally things like Bulk Delete, Merge records, etc. are self-explanatory.
When these options may be overlooked- and changes to CRM are made via code, changes to site map, using a ribbon editor- that could be handled by security roles, you lose some visibility to this even existing. If “Merge” records is gone from CRM, and even an internal System Admin doesn’t see it, how would they know to tell users it’s an option and it could be allowed based on Security Role? Plus, then if it is found without much digging, it’s awfully frustrating to think that permitting access in Security Roles can solve a problem, then have it not do so (and then you need to switch to a new plan. See Sanford’s post Sitemap Edits.
When in doubt- prior to making changes across the board to your CRM, consider what Dynamics CRM already provides as an option to users. We talk a lot about Best Practice in processes for sales, data management, and many other places- but there are equally important ways to work with Security in CRM.