Security Roles and Teams in CRM – An Inconvenient Half-Truth

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”.

Tom Cruise in A Few Good Men - I Want the TRUTH!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.

CRM 2011 2013 or 2015 Multiple Security Roles on User and Teams diagram

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).

Jake Sully - Avatar split personalityTo 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

Beverly Hills Cop film posterIn 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.

Global Warning

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?

32 Responses to Security Roles and Teams in CRM – An Inconvenient Half-Truth

  1. Simon Hetzel says:

    Blimey Adam – I’m not sure I followed all that completely. Everytime I run into security roles associated assigned to teams my head spins…

    I have often wondered (but never had the time to think it through properly) whether there should have been an extra access level between “user” level and BU level – perhaps something like “team members”-level? (Actually maybe similar levels are required between each of the current access levels) I wondered if that would magiacally make inheritance work – what do you think? Hum maybe not…

  2. Simon Hetzel says:

    Reading this has made me go back and look at a problem I had with inheritance with for a “user management” role that I had assigned to a team. It should have been working I thought – all the priviledges I had granted with the role had organisation-level access and so your 4th truth “Global Warning” should have applied?

    Going back to check again today I find that the prvApproveRejectEmailAddress (“Approve Email Addresses for Users or Queues”) still doesn’t work when assigned to the Team rather than the user. The error says “required depth: local” yet it’s already set to organisation.

    So now I’m not sure whether your 4th Truth always applies.

    Of course I guess this could just be a bug…

    [CRM Online, without Polaris enabled, one (default) BU – no others]

  3. ukcrmguru says:

    Thanks for the feedback. I think the biggest issue with Team security is that people often jump straight into using Teams for ownership, even when they have resistance from the business against doing so (because the want more accountability), but the designer says “well, if you want people to access these records across BUs, that’s the only way”. Simply being in a Team which has a role gives a “backdoor” to access records across BUs, without ownership.

    I don’t think a “Team level” access depth would be helpful – if you need smaller BUs, redesign the BU structure. Team-level would be an inefficient approach to figure out what access you have – I can read (for example) all records owned by any user who is a member of any Team of which I am a member – that could be thousands of users in hundreds of Teams, and I have ended up with a huge “where systemuser IN…” clause. The beauty of the BU model is that it massively reduces the complexity of the queries run to render a view, or the context for Ribbon buttons etc.
    This is a common payoff in system design – some up front complexity of the design thought process, but then this is massively outweighed by the time saved for every page view, every form load, for every user, every minute of every day. If I spend a whole week building out a complex model (unlikely, but an extreme example), and if the model means that every user who joins the organisation takes an extra 10 minutes to configure, that can still pay back for a business with 1000 users loading 1000 views a day and saving 10 ms on each one.

    As to the “special” miscellaneous privileges, I dare say they may not obey all the same rules all the time – it comes down to how those internal bits of code actually do their privilege checks. I only tested entity access, spending several hours with multiple users in different BUs with highly restricted and slightly different roles to be able to spot the difference between easily visible things like write / share / assign privileges on individual records.

    I’ll reword to clarify the “scope” of my rules, and if I get a chance I’ll document some of the more common misc privileges that people often want to apply via teams (I’m thinking especially of things like Bulk Edit, Export to Excel, Print, Go Offline, Send Email as another User…and I’ll add Approve Email to the list too!)

  4. Pingback: Why Use Access Teams in Dynamics CRM 2013 | CRMguru

  5. Santosh says:

    I have few doubts
    1. What does BU level or higher access level to Create privilege serve if it is sufficient to have user level Create privilege?
    2. When we share a record and while giving different privilege then AppendTo doesn’t come, why?
    3. How do Append and AppendTo privileges work in N:N relationship?

    Any one please clear my doubts?
    Thanks in advance.

    • ukcrmguru says:

      1) If you have only user level Create privilege then a user can only create records they own. If they have assign privileges they can then assign them to other users. Having BU or higher means the user can create a record and set the owner to be someone other than themself as part of the create step. This can be important if a Workflow will be triggered by the record creation, and perhaps email the owner. Likewise if an on-demand Workflow is used to create a record and set the Owner, perhaps to match the parent record. Or even just creating a child record from a parent with the Owner being mapped between the two entities.
      2) When Sharing, the privilege labelled “Append” will actually give Append and Append To permissions. As far as I can see, this is to make the dialog a bit simpler for end users – you can imagine the number of time you might have to explain or remind users which way round to use these privileges.
      3) Using a “real”, built-in N:N relationship, the user should need Append To permissions on both entities, since the hidden intersect entity has a lookup to each record. However, for the interface to work properly and provide the buttons to associate to an existing or new record (eg “Add new”) it seems you need Append permissions. In general, assume the users need Append and Append to on both entities in order for N:N relationships to work properly.

      Hope this helps

      • Santosh says:

        Thank you very much for your reply. I am completely satisfied with the answer of two doubts..thanks ..thanks a lot. However 3rd doubt is still not clear. I explain a scenario I have come across. While playing with Lead and Marketing List (both are having N:N relationship) we need to have AppendTo privilege on Marketing List and Append privilege on Lead, here I have confusion that though these two entities Lead and Marketing List are having N:N relationship then how come Marketing List is behaving as a parent. Separetlly I tried with two custom entities having N:N relationship, here we need to have both priveleges Append and AppendTo on both the custom entities to perform append actions.

        Could you please clear my doubt.

      • ukcrmguru says:

        When you create an N:N relationship between two entities A and B, the platform actually creates a third entity “C”, known as the intersect entity (or sometimes a link entity). This entity is completely hidden from you in normal use, but you can see the tables for it in SQL. It has a lookup field (N:1 relationship) to both of the associated entities. Whenever you associate a record of A with a record of B, the platform creates a record of hidden entity C, with lookups to A and B. So both A and B are parents of entity C, so users must have “Append To” permissions for A and B in order that the records of C can be linked to them.

      • Abhirup says:

        @ukcrmguru: “Whenever you associate a record of A with a record of B, the platform creates a record of hidden entity C, with lookups to A and B. So both A and B are parents of entity C, so users must have “Append To” permissions for A and B in order that the records of C can be linked to them”

        if I am on form C with entity A and B as Look-ups, I would need ‘Append to’ on entity C and ‘Append’ on A and B.

        But if I am on either of A or B entity with C on the left navigation (command bar now) or sub-grid, then I would need ‘Append’ on entity C and ‘Append to’ on A and B.

        I think what you said above refers to the 2nd scenario? Correct me if I am wrong.

      • ukcrmguru says:

        Firstly, in the scenario I was describing in the above comment, you can never be on a form for entity C, because in a native N:N relationship this entity is completely hidden from the UI. But if you created entity C with two lookups, you would have what is sometimes referred to as a “Manual N:N relationship” (although it is not really a relationship, just a way of designing and building the system).
        It does not matter where you are, or on which form, you always need “Append To” rights on the parent entity (the 1), and “Append” on the child (the N end). So in this setup, you always need “Append To” on A and B, and “Append” on C, regardless of where you are, including if you create and associate these records through workflows or plugins.
        Hope this clarifies things.

      • Abhirup says:

        @ukcrm guru: thanks for your feedback. I still have some questions. In case of a N:N relationship (manual or native), which entity is parent or child? I mean say entity A and B has a N:N relationship and I decide to have both of them as sub-grids on each other’s entity forms. How will the “Append/Append to” work in this scenario?

      • ukcrmguru says:

        As above in my earlier comments, neither A nor B is the parent of the other in an N:N. A third entity C is created that is a child of both of them (so it has two parents).

  6. ukcrmguru says:

    More details on those 6 special privileges that can only be set as “User” level, so they don’t work with roles assigned to Teams:

  7. On CRM 2011, I have a user that has no roles. This user belongs to a team with one role.

    This role has User level for Create, Read and Write. I find that the user cannot Create record unless the record is assigned to the team at the time of creation. This is as you described.

    However, after the record is created, the user can then read and write the record. So it seems this impersonation behaviour only exists when creating record? Are you seeing the same?

    • ukcrmguru says:

      Your user has no privileges to for themself, they only have rights because of their team membership.
      When they create a new record for the entity, the only Create privilege they have is at “User” level in the Team role, so they can only create a record owned by the Team. It is as if for a moment they “are” the Team and create the record with those privileges. So far I think we are agreed. Also note that even if the user did have Create rights for themself, they could not own the record since they have no Read privileges.
      Once the record exists, the Team owns it. The user still has no rights to the record from their own roles. They can read and write the record because of the rights they have as a member of the Team, through “impersonation” if you like. This is not inconsistent at all. If you take them out of the Team, they will lose the ability to see or update this record.
      Let’s change the scenario slightly:
      Give the User a role that has Create and Read privileges to the entity. Put them in a Team that has a role with Write privileges at “User” level.
      Now the user can create a record that they own immediately. They can read this record as well. But they cannot edit it, because they do not have Write privileges for themself. Although they have Write privileges through the Team’s role, this is only at “User” level, from the point of view of the Team. The Team does not own the record, so these privileges do not apply to this record.

      Does this help?
      Also, if you have users who have no roles directly assigned, you need to watch out for a few special privileges that might prevent them from working properly with the application:

  8. xun says:

    Thanks for sharing the security details.

    We have only 1 BU, I was hoping that I could only assign security Roles to the default team and since all users will be add to the default team anyway, user’s should be able to use those roles the default team has. I understood the catch you are talking about re “User” level access for a Role on a Team meaning the record ower has to be the Team.

    However we have another error whiles using security role assigned to Team and not directly to user. So the Security Role is set to have all permissions at BU level and assigned to Team. the user is a member of the team. The Entity have several forms (enable security roles set to “display to everyone”), and depends on some field value on the record, js use form.navigate() to display the record use the relevant form. However when I test as the User, I can open existing record fine. But if user changes the field value which triggers the form change, I then get the “you do not have enough privilleges to access or perform the requested operation….” error. Any idea?

    • ukcrmguru says:

      Yes, read my other post here:
      You will probably find the issue is related to the User Entity UI Settings privilege.

      Ideally, give your users at least a basic role with minimal privileges in, then add other roles via Teams if you want to.

      Also note that for performance reasons (that I intend to cover in a later post), you will get faster performance for a retrieve multiple (such as looking at a view) if you grant Read privileges to your entities at Organisation (=Global) level, rather than BU. The net effect will be the same because you have only one BU, but the system can determine that the user has access to all records purely from data cached on the web server. Also, for other privileges there might be a tiny improvement in opening records in a form if you do the same.

  9. Deb says:

    Fantastic article!!! I read and re-read this, while highlighting, scribbling notes in the margins, and laughing at the metaphors. What a great job of explaining a very complicated topic! I’m new to CRM with Online 2015 and stood up a case tracking system with no training, just trial and error. I just accidentally blew my System Admin privileges (no users in production yet) away by changing my BU. This fudging the settings was due to getting record level privilege errors when trying to assign records to a team. I’m not sure why that would happen with the elevated permission of an Admin, but I sure do understand a lot more after reading this article.

    I am now on to read more from your blog. Thank you again!
    Deb Silbert

  10. Ben says:

    Thanks great article

  11. Greg Kawinski says:

    Hi, in the newer versions of CRM (say 2013 SP1) users cannot be added to teams or security roles outside of their business unit.

    This makes things a little simpler but also more restrictive. I was actually hoping to leverage this to solve a complex sharing problem, and was surprised to find it no longer available, when I remember this being possible in CRM 2011. Oh well, it does eliminate scenarios which can seem contradictory, and probably reduces the instances of CRM administrators slapping their foreheads with gotcha moments.

    • ukcrmguru says:

      (sorry for delay in reply, been away on holiday)
      You can still add users to teams outside their own business unit. That has always been the point really, that teams do not follow the same hierarchy as business units. You can’t change the membership of the default teams (the ones that are created when you create each business unit and have the same name) – these always contain all the users in that business unit. But you can create teams in any BU and add users from anywhere. If the team has a security role then things do get more complex, hence this article in the first place.

      • Greg Kawinski says:

        Yahtzee! You’re right, one team can have members from multiple BUs. That makes my life a lot easier. Thanks for the reply.

  12. Patrick says:


    Users in my team cannot delete records owned by the team. Why?

    I have 1 Root Business Unit
    I have 2 Teams, all records are owned by the team itself (not user)
    I have just 1 “read only” role on the teams.

    I have a delete record security role which I add to users profile for those that can delete records in their respective teams. I set the permission level to user for delete.

    The users cannot delete the records owned by the team. Am I missing something?

    • ukcrmguru says:

      In security roles, as explained in the article, the “User” level for a privilege really means “whoever has this role”. So if your users have a security role that allows them to Delete at “User” level, then they can only delete records owned by the user. If the Team has a security role with Delete at “User” level, then users in the team can delete records owned vy the team. So it sounds like you need to put the delete privilege in the Team security role.
      Or rather, you probably should not, because letting users delete data from CRM is usually a bad idea for all sorts of reasons.

  13. Great article summarizing a bit how this works. We are in the midst of setting this up at our firm and this helped a great deal in understanding the inner workings of owner teams

  14. Marcel says:

    Great article. Helped me a lot!

  15. Pingback: Episode 58: Marketing, Dynamics 365, and the quest for the 1,000th tip | CRM Audio

  16. Pingback: Tip #526: Team is always more than sum of its parts | Dynamics CRM Tip Of The Day

  17. Pingback: Tip #301: Using a team for system administrator access | Dynamics CRM Tip Of The Day

  18. TMK says:

    Very nice blog.thanks man.

  19. Bernard says:

    Even after more than 4 years this is still a very useful article. Thanks for posting it!

Please feel free to join in the conversation below...

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: