In this webinar, our experts showcase a variety of demo use cases of how different components of the...
Traditional security management within Microsoft Dynamics CRM involves assigning a security role to a user or group of users. If the user changes roles, a new security role should be assigned. When job roles change, existing security roles need to be updated. Team-based CRM security can improve this process.
This role-based security management may work for some organizations, but it can be difficult to maintain when you have many users, users frequently change jobs roles or business changes often require you to create a new security roles. If that sounds like your organization, you should consider an alternative—a team-based model.
Team-based security may simplify CRM security administration for organizations that are experiencing rapid growth and/or transformation. In team-based security, the security roles are based on the entities rather than business roles. They remain consistent and are assigned to the appropriate functional CRM security-based teams. Then the users are assigned to the teams that align with their business functions. This way, as the organization changes, you need only understand how users align to functional teams rather than administer a long list of security roles.
This approach requires a fair amount of up-front analysis and setup, but take heart. It's all for the sake of your long-term CRM administration sanity!
Here's how to set up team-based security.
1. Analyze and document how teams and groups use CRM throughout your organization. For example, how many positions are in the Sales department? How does the Sales Manager use each entity differently than the Sales Consultants? What about in Customer Service and Marketing? Do all users in a department use the same entities, or are they divided into subgroups that work with different entities? Within departments, start grouping users together based on how they use CRM, such as:
These groups will form the basis of your CRM Security-Based Teams.
2. Create two security roles for each entity your organization uses: Read/Append and Create/Edit.
The picture below shows what the Read/Append security role looks like for the Campaign entity. Apply permissions on Read, Append, and Append To. Don't apply security permissions to any other entities in this security role.
You'd name this security role Campaign – Read/Append.
This is the Create/Edit security role for the Campaign entity. It includes the same access permissions of Read/Append, plus Create, Write, Assign, and Share. Don't apply security permissions to any other entities in this security role.
You'd name this security role Campaign: Create/Edit.
Set up a Read/Append and Create/Edit security role for every entity your organization uses. Setting up security roles based on how each entity is used creates a consistent foundation that will never leave you guessing which security role allows what access permissions. It also allows granularity in team permissions, as we'll see in the steps that follow.
(Note: Best practice is for Delete privileges to be limited to select users, such as System Administrators, not on these security roles. Alternatively, you could create a specific security role for Deletion privileges on an entity and assign it to select users or teams.)
3. Identify and document how each group in your organization uses each entity. Which entities does the group use? Do the users in this group Create/Edit records in this entity, Read/Append them, or do they not need permissions to the entity at all? Do all the users in each department require the same access permissions on the same entities, or is there a "Super" group who Creates/Edits on a particular set of entities and a "Basic" group that Reads/Appends?
4. Create the Security-based CRM Teams. Give the teams names that align to their business function or department, followed by their overall level of engagement with CRM, for example "Sales – Super." Ensure to select the team type of Owner.
Here is an example of what a list of teams may be named once they are created:
5. Assign the appropriate security roles to each team. In each team record, click Manage Roles.
Then select the Security Roles that align to the group's departmental responsibilities and level of engagement with the entity: Read/Append or Create/Edit. Keep in mind that a group may not require a security role on every entity. This provides the added benefit of a cleaner site map and navigation for teams.
6. Assign each user to the team(s)
that align to his or her department and level of engagement. Click the + sign in the User sub-grid to add users to your teams.
Now you are ready to administer security based on teams rather than security roles! Simply view the team's security roles and you'll never have to guess about a user's access permissions.
Keep up with business changes and transformations by:
Team-based security can take the pain out of CRM administration in a fast-changing organization. Go forth and administer!
Happy CRM'ing!
Thanks for a great article. Do you any more blogs which explains in detail when to use Owner vs Access teams? Something like do's and dont's.