Security Roles and Teams in CRM – An Inconvenient Half-Truth
June 25, 2013 27 Comments
Over the course of the last two years or so reading everything I can about Dynamics CRM, as well as teaching many classes of people how to get the most out of their CRM systems, one thing which comes up again and again is how to best structure Business Units, Users and Security Roles, and sometimes Teams as well to get the exact model you want to match your business requirements for who has access to which records and when.
Users inherit Security Roles from Teams – right?
One concept I have seen repeated many times is that “Users inherit security roles from all the Teams they are in”. And generally this seems to be a reasonable way to describe how it works, but occasionally odd behaviours seem to show up which make this appear to be less than 100% accurate.
I also had a gut feeling for a while that this was not the best way to describe the way this works. I prefer to say that “when a User is in a Team, they can act as if they are the Team, with the rights that the Team has through its Security Roles, but only while considering records in the same Business Unit as that Team”.
More on this later, and the one part of the model that this description does not do justice to.
Overall this means Security Roles use a kind of “impersonation” when Teams are involved and that the rights the User has are not only ‘borrowed’ very temporarily from the Team but they are relative to where the Team is – so access levels / depths such as “Business Unit” or “Parent / Child Business Unit” operate from the Business Unit where the Team is.
So how does this really work?
If you really want to read how security roles work in terms of determining access to a whole bunch of records (to display the results of a view) or a single record, then you need to read the white paper Scalable Security Modelling with Microsoft Dynamics CRM 2011.
42 pages later you will probably know exactly how the queries are built to actually enforce the security model, but that may not have made it much clearer from a practical, day-to-day design point of view. To be fair, the point of that white paper is to explain the underlying architecture and query methods properly so you can figure out the performance impact of different security approaches, rather than demonstrating how this informs your design from an end-result “who can see what” point of view. One thing that is never mentioned is any idea of inheritance or merging of privileges from Teams to Users. Every kind of access request is checked against User and Team permissions separately (exactly what is checked depends on things like whether the User has Global access level privileges to that entity at all, and whether the record is owned by the User or any of their Teams. These can help shortcut the otherwise brute force querying that would be necessary, especially to return all records in a view).
“You can’t handle the TRUTH!”
By now, I bet some of you are ready to shout at the screen – “we know Users don’t actually inherit the roles and keep them for themselves, but it works just as if they did, so it’s just a kind of shorthand and we all understand what we really mean, so don’t be pedantic”.
I always argue that I am not pedantic, I just like things to be exactly correct – “I want the TRUTH!”
In this case, it is CRM which is pedantic, and does not always behave as expected if you believe that a User can act as if they have all the Roles that their Teams have, all of the time. If you are betting your security model on it working this way then either you will end up with Users who can’t do their job, or possibly a gaping hole in your security. Neither sounds good to me.
So, before we go much further, let’s get some terms out of the way and then look at how things really behave.
Terms of reference / definitions
“ ‘When I use a word,’ Humpty Dumpty said in rather a scornful tone,
‘it means just what I choose it to mean — neither more nor less.’ ”
- For the sake of brevity I will simply use the word “Role” rather than “Security Role”.
- Any talk about Teams only includes Teams which have a Role. Those which do not play no part in the security model (they may give access to role-based forms, or provide some view or report filtering, or escalation paths for workflows, so they are useful, but not to the matter at hand).
- A Security Principal is an object which can have rights assigned to it. That means in CRM a Security Principal is User or a Team and this means records can be owned by either of these. (In other systems, a Security Principal will mean all sorts of other things – in Active Directory it would include Users, Computers and Security Groups, for example). I’ll try not to use the term too often though.
- I will try to be consistent in my use of terms: a Privilege describes an action that can be taken, such as Read, Write, or Delete. Access Levels describe the “depth” to which you can do this – which records, in other words. This works in a sort of “concentric circles” approach outwards from the user (or downwards through the hierarchy if you prefer) from none, through User-owned (aka Basic, but I’ll stick to User), to Business Unit (BU or “Local”), Parent-Child BU (PCBU, aka “Deep”) and finally Organisation (“Global”).
- I will use the phrases “security rights” or “access rights” much more loosely in a totally cavalier fashion to mean whatever I want depending on context. I will probably also talk about “access” to records to avoid referring to a specific privilege when the point at hand would apply to read, or write, or delete etc. equally well.
- As a reminder, a security principal can only own a record if it has at the very minimum a Role which includes the “read” Privilege to at least User level for that entity. So a Team with no Roles definitely can’t own records.
- As another reminder, a User or Team must be in exactly one Business Unit. A User can be in many Teams from their own or other BUs. Teams can contain from zero to many Users, but cannot contain other Teams. Users and teams can have zero to several Security Roles.
- Every BU contains a Team which shares its name, is created and maintained for you, and always contains all the Users who are in that BU at that moment. Each of these is called the “Default Team” for a BU, and you cannot add Users from another BU to this Team, although the Team can be assigned one or more Roles, and this may be useful for one particular approach to the security model (more later). Generally, this article is concerned with Teams you have created which may contain Users from other Business Units.
- Throughout the article I will discuss Users and Teams as if they each have only one Role. If a security principal has more than one Role assigned, you can simply treat them as being merged together into a single super‑Role with the greatest level of Access for each of the Privileges from all the other Roles (at least this bit works like you thought it did!). So you can treat the three Roles a User has as being merged together, and the two assigned to their Team as if they are one, but you can’t merge the User and Team ones together.
- I will use some “shorthand” such as “a User’s Teams” to mean “all the Teams a User is a member of” (as opposed to the Administrator of), and “records which are in Business Unit X” meaning “records owned by a security principal which belongs to Business Unit X” (although the BU is a property of the record, it gets updated if the owner moves around, and it is important to get this right when we try to consider how a user can create a record in another BU)
Right, now you have some idea what I am talking about, let’s deal with our first “truth”:
One Business Unit to Rule Them All
1) If you only consider one Business Unit, then the CRM security model largely behaves as if the User inherits all the Security Roles from all the Teams they are a member of, and can use those rights all the time.
In most cases, Users will have at least one Role themselves in order that they can log on to CRM and do their basic work, and they may then get additional rights from a Role assigned to a Team, such as “Managers” to allow them to Assign records they do not own (maybe regular staff can only assign records which were theirs to start with).
So when people quickly test this stuff, it may not be possible to tell the difference between how this ‘inheritance’ really works and how it appears to work within a single Business Unit, because the really essential stuff is in the User’s own Role(s) and they are only inheriting some extra, greater permissions from the Team’s Roles.
To be totally clear, when I say “If you only consider one Business Unit” I mean either that you only have a root BU as your entire Organisation, or that a User is only a member of Teams from their own Business Unit. When a User is a member of more than one Team from the same BU, and/or those Teams have more than one Role assigned, you can simply treat this as if all those Roles are merged into one, with the most permissive privileges from each, added together, as shown in the diagram below (click for larger version). This does not apply when the Teams are from different BUs, as we will see.
To make this a more concrete example, we have three Business Units under our root BU, called A, B and C, so there are also three default teams (plus one in the root BU) – Team A, Team B and Team C. I have six Users called Alice, Alan, Bob, Barbara, Charlie and Camilla, two in each BU, and by definition each is also in their default Team for their BU.
Alice has a Security Role which gives her no access rights to Delete any records at all, and only allows her to Assign Accounts, Contacts and Opportunities which are user Owned. Team A has a Security Role allowing BU level Read and Assign for these same entities, so Alice (as a de facto member of that Team) can Assign any records of these types owned by her, or Alan, or indeed Team A.
Now let’s look at one bit of detail that catches people out, and is really quite important:
2) If a User has no Access to a particular Privilege in any of their own Roles, and they have a Team Role which grants only “User” level access to that Privilege, then this only allows the User to do that action to records which are owned by the Team
Why is this so critical? Well, if you have a Role which grants the Create privilege (for example) at a User level for some entity, and this Role is only assigned to a Team, then any user in that Team can Create records of this type, but only if they make the Team the Owner before they save the record. If they try to save the record with themself as the owner, the security model looks at this and says: “you do not have the right to create this type of record. But over here, you are a member of a Team, so acting as if you were that Team you can create these records, but only for “you”, by which I mean the Team itself, not you, yourself.”
The User has not inherited the ability to create records they own. They are able to “impersonate”* the Team for a moment, and do all the things that Team can do, but in a way which is ‘relative’ to the Team record, so in this case the Basic or User level means with the Team as the Owner. (this level is misleadingly named simply “User” in the Security Role editor interface of course, but this is inherited from CRM 4.0 when Teams could not own records).
To pick on another film-based metaphor, this “impersonation” is a lot like having an Avatar – someone who can go into a different environment on your behalf, and while there they have skills and abilities you don’t normally possess (like working legs, or the ability to ride flying banshee creatures).
The Avatar gives you access into places you could not normally go, but can only influence things in their own way – you can only fly the mountain banshee which your Avatar has “bonded” with, you can’t fly another (so this is a “User” level of “Ride” privilege), and you (your real self) can’t bond with any at all, since you are not blue and don’t have an extendible neural interface (privilege level = “None”).
*(Aside, for developers and pedants: I am not using the term “impersonate” in any special technical way here, and definitely not in the sense you would use it where a user or service can present the credentials of another security principal and actually pretend to be them. Any actions taken by a User which use rights they have because of their membership of a Team which has a Security Role are still carried out by the User, and system fields such as Created By and Modified By will reflect this, as will any auditing.)
Back to our scenario from above, now we add a Role to Team A which grants the “Delete” privilege to Opportunities at User level. Alice cannot delete Opportunities owned by her or Alan, since she has no rights to do so herself. When taking on the Team’s roles, she still cannot delete Opportunities owned by her (or Alan) since the Team can only delete Opps owned by “me”, which means the Team. She could Assign the Opps to the Team (which has the rights to Read them,m a requirement to allow ownership), and then Delete them. You could consider this a backdoor in your security which needs closing, or a sufficient barrier to prevent accidental deletion while allowing users to do it deliberately when necessary.
The best metaphor I have for this is when someone holds a particular job, this may give them rights associated with the office they hold. Whether this is something trivial like the authority to order stationary or sign a cheque, or more serious actions like sending criminals to prison, or declaring war on another country depends on the job they are in. Before they had that position, and after they leave it, they do not have the right to do that. Just like adding or removing a User from a Team, they only have the ability to use the Team’s Roles while they are in it.
Also, in most cases, a job or official position only allows someone to use their powers while they are doing their job, in the right context. A judge can sentence a criminal, but only in his or her own courtroom which they are presiding over. They can’t do the same when they are down the pub, or sitting in another judge’s court, even though they are still a judge and still have that job. So here the privilege to “sentence” an entity called “criminal” can only be applied to “criminals” which are “owned by” the court (team) the judge belongs to. I know this is stretching a metaphor a bit thin, but I think it does actually help this to make sense.
What about using Team roles for everything?
A popular idea is to create a “baseline” Security Role with all the basic permissions needed by users to at least log on and do their basic work that they all have in common, then assign this to the default Team of a Business Unit (or to all default teams of all BUs). Sounds great: every user will be a member of their BU’s default Team automatically, so they will be able to do their job without you having to remember to assign them to a security role – or will they?
Well, if the role has lots of “user” level access to different Privileges then you may have to look at making the default Team the owner for these records so that the user can use these privileges. If the User or a colleague is the owner, then User level privileges just won’t cut it, as the “User” who has the rights is the Team, via “impersonation”. So, what you could do is simply raise the access level a little, to BU (Local). Now, when acting as the Team, the User can perform the action against records owned by others in the BU.
Since this is the Default Team for their BU it is by definition in the same BU as the user, so this is just the same as if they had that access directly for themselves – they can act on records they own, ones their local colleagues own (meaning other users in their BU) or those owned by the default Team or any other Team in this BU. Now this looks a lot like inheritance, so if you want to think of it that way when considering only one BU at a time then go ahead.
Why not just assign roles to Teams then?
There are two key reasons not to do this. Firstly, you may actually want Users to only perform certain actions on records they own, such as writing (editing) or assigning Opportunities. If the Team owns the records, the user needs BU level rights in their own roles (which gives them rights to other people’s records, which we don’t want), or the Team needs User level access, and then any member of the Team can act on all the records the Team owns, which we also don’t want. If the User owns the records, and they are only getting rights via the Team’s Roles (and have no Roles of their own), then the Team would need to have BU level access for the User to be able to act on their own records, but this would also give them access to other people’s.
So, as a rule of thumb, Roles assigned to Teams are great for giving very broad access to things you deliberately want to be wide open, such as letting all Users read all Accounts and Contacts in their BU (or indeed their Org).
Let me in!
The second snag with assigning Roles only to Teams is that there are a few fundamental privileges a User needs in order to be able to log on and do some really basic things. Five of these settings can only be set to None, or User level, there is no option to set them higher. The settings that are most fundamental are User Entity UI Settings and User Entity Instance Data, which save information about the user’s environment and recent usage. The others which really help users to get through the day are Saved View, User Chart and User Dashboard. (Update: These are discussed in more detail in my new post Special privileges in CRM Security Roles.)
This would mean if privileges for these areas are granted in a Role assigned to a Team, then the user can only change settings for the Team, and create new views for the Team and so on, and unfortunately that does not really work – the user MUST have the rights to create, edit and delete these items for their own records/settings. (OK they don’t strictly need to delete saved views, charts, and dashboards but it helps them clear out old stuff they don’t want any more). So the end result is that Users must have these sort of settings in a Role which is assigned to them directly, not just assigned to a Team they are in, otherwise some things just will not work.
(A couple of additional points here: there are various other privileges needed to log on and work with CRM properly such as reading Team and User information, system forms and all sorts of other stuff. This is not the article to cover what those all are, (this one is a good start) but the key point for us here is that all of those other privileges can be set to levels higher than “User” – often they are Organisation-owned anyway so it is all or nothing. Because they are not limited to User level, they can perfectly well be added to a Role assigned to a default Team and that will give users the rights they need.
Secondly, if you take a look at the System Administrator security role that has everything set to Global, except for these five which are set to User. This is a good way to spot which they are. It also means that you can’t hack the settings by editing the xml for a role to grant them at Local or Global level for example and importing it in a solution – you cannot create a role with privileges in it which are greater than privileges you already have yourself. Since none of the built-in roles have more than User for these five, no-one can create or import a role, in any way at all, to grant more than this level.)
The Beverly Hills Cop Rule
In case you were not even born back in 1984, in the film “Beverly Hills Cop” Eddie Murphy plays a cop from Detroit who goes on vacation to follow up the murder of a close friend – a case he has been forbidden from working on.
While there he gets into all kinds of trouble by going round town and acting like a (somewhat maverick) police officer when of course he has no jurisdiction in California.
This is a great metaphor for our third insight into how CRM security roles operate when Users are members of a Team in a ‘foreign’ Business Unit:
3) Whatever rights a Team has can only be used in relation to records in the same Business Unit as the Team, and even then only to the access level provided by the Roles the Team has.
So, to put it another way – you might be in the Cop Team over in the Detroit Business Unit, but here in the “folks on vacation” Team in the California BU that does not give you any more rights than any other citizen to carry a concealed weapon and get thrown through shop windows.
Hopefully this will make sense anyway if you follow the rule that a User gets to use the rights from the Roles assigned to their Teams, but when they do, they are acting as if they are the Team, and all Access levels are relative to the position of the Team. It also means that while acting as the Team, they don’t get to use their own rights from Roles assigned to the User directly. If they have BU level access to something, this only applies to their own BU, they can’t use these rights on their User while
So, in our previous scenario of three BUs, we create a new Team called “A-Team”, so this can contain Users from any Business Unit (unlike the default Team A we used earlier), and assign the same Role we used earlier, so this has BU level Read and Assign privileges on Opportunities. We add Bob to this A-Team. Now Bob can Read and re‑Assign Opportunities owned by Alice, and Alan, and Team A and our new A-Team. But if he tries to Assign a record owned by Barbara, in his own BU, it does not work – he can’t use the rights from A-Team over in Business Unit B, which is across a security boundary (“in a different jurisdiction” if you like).
This is simply an extension of the thought process to the same rule we already covered. When considering his access to records in BU A, Bob can “impersonate” A-Team, which has access to all of these records across the whole Business Unit. But when applied to records in BU B, even if you want to think of Bob as still having this Role, it is with respect to the relative position of the record (in BU B) and the Role-holder (A-Team, in BU A).,
Recently, Neil Benson wrote a great detailed article about Using teams to solve complex record sharing scenarios in which he examined a relatively common sort of request to give some users (but not all) the ability to work on all records in some other BUs than their own (but not all). I thought he was going to show how you could do this simply by making the users a member of a Team in another BU (in his scenario, a red BU user might be in the Blue Team, but not in Green, while a Blue BU user might be on both Red and Green). If the Teams in question had BU-level access to the relevant records, this would simply be enough on its own. The Teams do not have to actually own any records at any point, there is still no need for them to be shared explicitly nor implicitly (so no POA table to consider).
Neil did go on to explain that when a user then creates a child record it would, by default, be owned by them, and therefore “belong to” their own BU, not the BU of the Parent Record, so it might not be visible to that record’s owner, and definitely not to the owner’s BU colleagues. So he recommends a plugin to re-assign any new records to the “sharing” Teams, whereas I would suggest re-assigning them to whoever owns the parent record. In my approach, the teams are simply a kind of “back door” to give a user rights in a BU they would not otherwise have – a bit like giving Axel Foley his gun back on the streets of Beverly Hills.
4) When a User is in a Team which has a Security Role, any privilege granted in that Role at “Organisation” (=“Global”) Access level to an entity will give them those rights all the time, for records of that entity across the whole Organisation, regardless of where the Team is in relation to the User or record.
Finally we find a part of the model which actually does work in a way which matches the description of “Inheritance”!
Of course, it is just another example where the previous approach still stands up, but is less obvious, and may mean you could easily give users a level of access you did not intend. It also means our description for item 3 is a little misleading, or at least needs an extra caveat.
In our on-going scenario, Bob is in the A-Team from BU A. If we add a privilege to the Security Role that A-Team has, to give Organisation level read privilege to Cases, he will be able to use this privilege to read all Cases in BU A, and his own, and BU C, D or Z – Global means what it says! He is doing this by acting as the Team, then considering whether the records are in the same Organisation as the Team (not Bob), and of course they are.
Taking a further example, let’s say your senior managers are all in their own Management BU – it makes no difference whether this is above, below or at the same level as your other BUs for this scenario. You create a Team called “Managers” in that BU and assign a Role to give them read and write access to all Opportunities in the Organisation. Maybe one of your regional managers needs read access to the sales Opportunities which are owned by these senior managers (for big deals) to include some of them in their forecast report or dashboard. They should only have access to their own regional BU and the management one, not the other regions, so you don’t increase the rights in their own user Roles. Instead you add them to the Managers Team in the Management BU. Great, they can now read all the Opportunities they need! But unfortunately that Team has Global access to Opportunities so they will have access to all Opps across the Organisation, which was not the intended effect.
(The right approach would be to put the regional manager in a Team in the Management BU with only BU level access to Opps. It might be simplest to adjust the role on the Managers Team to only BU level, and add a Role to the Management BU default Team to give the Global access – you cannot accidentally add a user to that default Team unless they move BU, so there is less risk)
Recap and summary
I said earlier that my usual way of describing this security model behaviour with multiple Teams and Roles is: “when a User is in a Team, they can act as if they are the Team, with the rights that the Team has through its Security Roles, but only while considering records in the same Business Unit as that Team”.
The minor confusion here is that the global access works all the time, not just in relation to the Team’s BU. So a better way to phrase this would be:
“when a User is in one or more Teams, they can act as if they are each Team in turn, with the rights that Team has through its Security Roles, taking into account the relative ‘position’ of the record(s) in question and the Team, compared to the depth of access level each privilege has”.
A bit less snappy than “users inherit rights from roles their Teams have”, I’ll admit, but a lot closer to the truth, I hope you agree. Do you have any experiences of behaviour in CRM which don’t seem to fit this alternative way of looking at things? Or does this approach now make sense of things which you previously could not figure out with the “inconvenient half-truth” of inheritance many of us have been using for the last couple of years?