Tip #2: Use a base security role

When you implement Microsoft Dynamics CRM and have multiple levels of user security, management of security can get complicated. If you have 20 different security roles and you want to add entity access for all users, if each group has a distinct security role, you have to add the permission to each role.

Security design can be simplified by using a base role. Identify the permissions needed to log in to CRM and the common permissions needed by all users. Maybe start with one of the limited out of the box roles, such as salesperson, and copy the role. Compare the privileges needed by each group, and note where they all intersect. For example, if one group needs read access to accounts and another need read/write access to accounts, give your base role read permissions to accounts.

The result will be a single role with the basic permissions needed by all users. Give this role to all users. Then define group specific roles, only in these roles only include the permissions that deviate from the base role. Give each group their group specific role, along with the base role.

This will significantly simplify your security design, because in future phases when you want to add a new entity to which all users will need access, you can just add it to the base role.

Tweet about this on TwitterShare on Facebook0Share on Google+0

2 thoughts on “Tip #2: Use a base security role

  1. Lina Baumberger says:

    Has anyone created a base security role template for the OOB attributes? I have found that some of the privileges have non-obvious dependencies. I changes our existing Org to a layered security model but still occasionally find that I reduced or removed a needed dependent privilege to a level that is too low for a common action.

    • Joel Lindstrom says:

      Hi Lina,
      you are right that it is a little tricky, and the base role for each deployment would look a little different. Also, each new update seems to add new permissions, so you want to revisit it each update. Next week we have a tip about some changes in queue permissions needed after SP1 for 2013.

      What I usually do is create a spreadsheet where I have each logical group and by entity what they need. Whatever is the lowest level of permission for each entity I build into the base role.

      I start with a role like salesperson. I leave the customization and business settings unchanged, unless there is a specific reason why the base role should not have it–such as excluding export to excel, etc.

      Hope that helps. I don’t know of a template out there.

Leave a Reply

Your email address will not be published. Required fields are marked *