Security Roles, when assigned to a user or a team, determine what users can and cannot do in a Dynamics CRM organization. Security roles are probably the most complex concept in the Dynamics CRM security model. I wrote an article an earlier article about the related concepts of business units, users and teams, but security roles deserve their very own article, and here it is. Also, this article was prompted in part by a question I got from a reader, so Chandon, if you’re reading this, skip to the end for the answer to your question!
Security Role Basics
I’ll start with a few basic facts about security roles. For the most part, security roles determine the access level a user has for privileges on every entity in Dynamics CRM. So what does that mean?
- Privileges are the verbs in CRM: Create, Read, Write, Delete, Append, Append To, Share, Assign.
- Access levels, from most to least generous: organization, parent-child business unit, business unit, user, none.
- Entities are the units to which a security role applies an access level for every privilege.
This three-dimensional model is what accounts for the very colorful and initially somewhat overwhelming security role UI. The following two figures show the most generous and least generous out-of-the-box user security roles:
The CEO-Business Manager Security Role, Core Records Tab
The Salesperson Security Role, Core Records Tab
The Salesperson role is more interesting since it consists of things other than just completely filled in green circles, so I’ll explain these concepts in terms of this role. I’ll provide some examples to illustrate the trickier concepts.
Privileges
- Create: Create a new record
- Read: Read access to a record (if you search for it in Advanced Find or a data grid, can you see it?)
- Write: If you have a record open on a form, can you make changes and save them?
- Delete: The easiest one to understand!
- Append: Can you append this record to any other record? Example: if you don’t have any append privileges for the Contact entity, you cannot associate any contact record with a parent account.
- Append To: Can you append any other records to this record? Example: if you don’t have any append to privileges for contacts, you cannot associate notes or activities to contact records.
- Assign: can you change the owner of a record?
- Share: can you override the security model by sharing a record with somebody who otherwise wouldn’t have access to it?
Entities
These are the y axis, and it’s the intersection of these and the privileges on the x axis that determine how much of any particular privilege you have for a specific entity. Notice that the Core Records tab contains the customer (account and contact) entities, along with the “potential customer” entity (lead). It also contains Opportunity (not displayed in the figures, but it’s there!), Activity, Note, and a lot of other things.
Access Levels
Since it’s the intersection of the entity and the privilege that determines what you can do, I highlighted the Contact row in the figure. For most entities – all record types that can be assigned to a user, the so-called “User-Owned” entities – there are five access levels for each privilege, from least to most generous:
- None:
The easiest to understand: you cannot do it! - User:
You can do it for records you own. Notice that the Salesperson role has user-level delete privilege for contacts. By default, a user assigned to this role can delete contact records assigned to them, so if you don’t want this, empty out the circle to set it to None. - Business Unit:
From User to Business Unit is a big jump, since it broadens out to include any record you own, plus any record owned by anybody else in your business unit. This is also the intersection between business units and security. - Parent-Child Business Unit:
This one only matters if your business unit structure is complex enough to have parent and child business units. If it is, the jump from Business Unit to Parent-Child Business Unit extends your access level down to any BU that is a child of the one you are assigned to. - Organization:
Also easy to understand, organization-level access means you can do it for any record owned by anybody in the organization. For example, notice that the account, contact and lead entities all have organization-level read privilege even in the least generous security role. Lots of organizations don’t want this level of visibility for a low-level security role, and thus might dial this back a little bit.
Customizing Security Roles
I’ve mentioned a few examples where many organizations will customize the default security roles. This topic has a few important basic facts of its own, such as:
- If you create new (that is, non-default) business units in your Dynamics CRM organization, every one you create will be a child of the root (default) business unit.
- That’s important for security roles, because every new business unit you create will inherit all of the security roles of its parent business unit. That is, security roles live at the business unit level, and any time you create a business unit, every security role of the parent is pushed down as an inherited role.
- And in turn, that’s important because inherited security roles can neither be deleted nor modified.
You might compare Dynamics CRM business units to sites in a SharePoint site collection: in SharePoint you can “break” security in a sense, configuring a child site in a collection to NOT inherit security from its parent site. You cannot do this in Dynamics CRM.
For example, the security roles shown in the above figures were security roles for the root business unit, so if you wanted to make changes to them and apply those changes to any existing child business unit (or any child business unit that might ever be created in the organization), you could do that. But…if you’re careful you can select a child business unit in the security role data grid, like this:
If you do that and open up one of the security roles, you will see something like the following:
The scary red text tells you what you need to know! So what does this mean for customizing security roles? Here are some of the most important implications:
- If you want to customize an existing security role, you can only customize it in the business unit it was created in. So make sure to select the business unit in the Business Unit drop-down as in the previous example.
- If you do customize a role, the changes you make will cascade down to all existing or future child business units.
- If you want to create a new security role and have it available for every business unit in your CRM organization, create it at the root business unit.
- If you want to create a new security role and have it available only for a specific business unit, make sure to create it only after selecting the business unit in the Business Unit drop-down!
I get questions having to do with this last point a lot, so I’ll emphasize it here. If you click the New button in the following figure, you will be creating a new security role that lives in the West business unit. It will not be in the parent business unit or any peer business units.
On the other hand, the following figure shows the security roles for the root business unit (note that the organization name is the same as the business unit – that’s how you can tell, provided you haven’t changed the name of the root business unit!). If you click the New button with the root business unit selected, the security role will push down to any child b.u.’s as an inherited role, and you will only be able to customize it at the root b.u.
Create a New Role, or Copy an Existing role?
Finally, if you do need a new role, there are two ways to create it:
- You can click the New button.
- Alternatively, you can select an existing role, click the More Actions drop-down and select Copy Role…
Generally it’s better to select a role that’s close to what you want and copy it. If you create a new role from scratch you might freeze up when you see this:
Just remember: whether you’re creating a new role from scratch or copying an existing role, make sure you’ve got the right business unit selected in the drop-down before you do. Security roles are definitely hard-wired into the business unit they’re originally created in, so you have to be in the business unit the role is for before you create it!
Security Roles in CRM 2011: What’s Different?
The core functionality of security roles is essentially the same in Dynamics CRM 2011 as it was in 4.0. For example, everything I said above in the current article works the same for 2011 as it did in 4.0 (with the exception of being able to rename business units in the new version).
But that being said…there are significant differences in the overall security model. How can that be? Turns out there’s more the security than just the “how security roles work” question. Two of the most important areas of difference in comparing the two versions:
- There are a lot more entities to which security needs to be applied. For example, charts and dashboards didn’t exist in CRM 4.0, and now that they do…we need security for them. Here’s an article I wrote on on example of that: Charts and Dashboards: who can see what?
- Teams are now a full-fledged security principle — that is, records can be directly assigned to teams. Here’s a short article I wrote on that topic: Managing Users, Teams and Security.
These are both important topics, and big enough ones to deserve more detailed treatment than those articles. More coming soon!
