In this blog post I will continue looking at the security features in CRM with regards with understanding the information for the MB2-703 – CRM 2013 Customization and configuration exam.
I will be focusing on
- Manage access.
- This topic may include: manage users and teams; configure sharing; manage Security Roles for users and teams; create Access Team Templates; add Access Team subgrids to forms
To see the topics in CRM 2013 then watch the video
This involves users/teams and sharing records and components and a little bit about authentication
The security authentication in CRM is not really handled inside CRM. A bit like the way CRM lets outlook/email router do all the emailing, CRM also gets another piece of software to do the authentication of users.
most commonly user records are linked to active directory
You can also used Internet facing deployment (IFD) where the authentication is either
AD FS (active Directory Federation Services)
STS (Secure Token service)
Microsoft Online Subscription Program (MSOP)
Either type of authentication the security authentication is done and then if successful the user are signed into CRM and then CRM applies the correct security roles, privileges.
There are a number of functionality to manage users and you can find these by going to Settings – Administration
- Creating users, teams, Security Roles
- assign/move users to teams, assign security roles to teams and users
- Disable business units
- Delete Security roles, Delete teams
- Move users between teams
each user can have one manager assigned to them. The manager look-up can be found on the user record, I think it’s used in routing.
Security roles – Security Privileges
Business management tab has the security privileges
Field Level Security
Enable or Disable user
Re-parent business unit
enable or disable business unit
Disable a user
you cannot delete users in CRM you can only disable them
If you disable a user the user won’t be able to log into CRM
a disabled user doesn’t use a CRM license
The records assigned to the user are still active. Best practice is to assign all the records assigned to the disable user to another enabled user.
You need to work out if the user is used in the workings of any workflows, these will still work but it’s not good practice to assign records etc to an disabled user.
Teams are optional
Two types of teams Access teams and owner teams
Owner Team can own records
Owner Teams can be assigned security roles
Access teams cannot own be assigned security roles or own records.
An owner team can be converted to an access team
An access team cannot be converted to an owner team
Business units and default owner teams
Business units have a team created automatically, the team name will have the same name as the business unit. Any members created and assigned to the business unit will automatically be added to the default business unit team.
It’s a dynamic team which CRM keeps up to date.
It cannot be edited but you can assign security roles and these security roles will apply to all members of the business unit.
default business unit team cannot be re parented, deleted or renamed and it’s members cannot be modified.
default teams can be converted to access teams but you cannot convert access teams to owner teams.
In CRM you can share records between users and teams. Sharing gives the user being shared to the same privileges to that individual record as the user who is sharing.
Sharing bypasses business unit – access level parts of security because when you share records it basically ignore the level (organisation, business unit, user)
Sharing records to a team is like sharing the record with every member of the team, except in the PrincipalObjectTable this is only one entry
using the business unit default team you can share records to all users in different business units.
Share more than records
Not only can you share records but also Charts, Views and Dashboards.
Users can only share their personal views, charts and dashboards.
When a user shares the components (charts, views and dashboards) they also choose what privileges you want the user/team to have with the component
Re-parenting a user/teams business unit has a drastic effect on the security roles the user or team had, it REMOVES THEM ALL.
So if you ever change a user/teams business unit you will need to assign the user or team some security roles in the new business unit.
This sounds drastic but it actually makes sense if you think about it logically. Each business unit has it’s own set of security roles, these are usually copied down from the parent business units. So when you move business unit, it removes all the security roles and it can’t automatically add them all back because not all the security roles may exist in the new business unit or the security roles could be vastly different with completely different privileges, so the user must add new security roles.
This is also true if you reparent a whole business unit because all the users will have had all their security roles removed.
Remember users without security roles cannot log into CRM.
If a user is re-parented they lose their security roles but they won’t be removed from any teams, this would probably allow them to login to CRM but the user won’t be able to change any personal settings, or view any components the user created.
If a team is re-parented then every member of team will lose all their security roles because the team will have had all it’s security roles removed.
An efficiency trick is if you want to remove all the security roles for a user or team is to move business unit