This is part II of my previous post on data driven security where I mainly focus on Security Roles and Business Units architecture, you can read it here:
http://quantusdynamics.blogspot.com/2012/03/dynamics-crm-data-driven-security.html
On part II I will focus on Teams and it's concept around data sharing based on the same pyramid model used on Part I. I'm also covering how can teams leverage User management. In general Teams are great for:
- User Access Management and Security roles
- Sharing Data across Business Units
- Enhance collaboration
User Management Simplified with Teams
User management in CRM can become as complex as you want. The management side has been designed to be very basic, adding a user and assign a security role, this is what it takes to give a user access to CRM. However with multiple business units and multiple security roles and the lack of a built-in tool to check 'effective permissions' across the hierarchy of records and Business Units this could become very time consuming to manage and troubleshoot permission issues.
You could add users multiple security roles at the same time, however you can't remove them at the same time, if you assign 300 users the wrong security role, you will need to remove one by one the same security role or develop a tool to do this.
However we are lucky because we have teams which can be used like AD groups or sort of OU with GPOs. How would this work for User Management? When we create a Business Unit, CRM will automatically create a team with the same name as the Business Unit you just created and link it with the same Business Unit. On Part I, I've used a pyramid type graph to illustrate permissions, the below screenshot is the same graph but I'v added highlighted in yellow the corresponding teams.
On the above graph, all the default teams in yellow belong to their own BU, also all users moved to that BU will also be automatically added to the BU default team, this is great!! However the default teams are not assigned a security role, even better! :)
At this stage what you need to do is assign a security role to the default teams, the appropriate security role with permissions only for those Business Units.
Now that all your default teams have a security role, if you didn't have users in the system, here is how it would work:
- Add one or multiple users to CRM and simply select the business unit you want to place the user on, don't assign security roles
- The user will inherit the Teams security role and it's permissions
- For those familiar with AD, this concept is similar to OU GPOs, every object you place on an OU is bound to the OU GPO's
You populated all users across all Business Units, now you have 50 Junior Engineers to move to the Global Engineers OU, this is how it would work:
- Select The users you want to move, and click 'Change Business Unit'
- Users will be automatically assigned the Global Engineers Security role because they are automatically added to the GlobalEngineers default team.
- Also users will be automatically removed from the JuniorEngineers team so they will also loose the JuniorEngineers Security role
- Conclusion: you didn't have to remove or add security roles
 |
| Assigning Users Business Unit |
Sharing Data
On the pyramid model the idea is to isolate data from other departments and teams, only specific permissions would grant the Junior staff tier access data on the upper Business Units, the only permission setting that allows this to happen is the 'Organisation' level and this would open access to all BUs and not just the BU directly above, we don't want this to happen because it would break the pyramid model so we have to use teams to share data with groups of users or the entire BU.
Facts about teams:
- Teams can only include users
- Teams can include users of any Business Unit
- You can share records with Teams from any Business Unit
To use teams to share records you create custom teams on the various business units, to be used as:
- Using Security roles to provide single BU access
- Object Access (record only)
Using Security roles
This method is familiar to us, we covered the concept on simplifying user management above. The team is assigned a security role so any user added to this team will also inherit the same security role, this is a great approach to give specific users in the junior tier, access to an external BU in this case the global engineers Business Unit.
Object Access
Instead of providing external BU access you may just want to share 1 or a few records with a number of users and teams, to do this you share data directly at the object-level (opportunity, account, etc).
- Create custom teams to group users
- On the record itself select Share and select the team you want to share the record with.
- This means any team from any BU could be added, and the record accessed by multiple users from multiple Business Units
- This avoided giving BU-wide permissions just to share one or a few records
The above diagram illustrates the concept of sharing records with Teams, team1 On the Junior Tier has been given share permissions on:
- One Record on the Global Engineers BU
- One Record on the Global Exports BU
A team from the Global Engineers BU has been also given access to a record on the Global Sales BU. I haven't illustrated the BU single acces because this is covered on the above diagram.
All users members of these teams are now able to view the records and if edit permissions were given able to write and collaborate.
Conclusion
I hope this was useful, please leave your feedback or any questions you may have.
