Looking for PowerObjects? Don’t worry, you’re in the right place! We’ve been part of HCL for several years, and we’ve now taken the final step in our acquisition journey: moving our website to the HCL domain. Nothing else is changing – we are still fanatically focused on Microsoft Business Applications!

PowerObjects Blog 

for Microsoft Business Applications


Administering Team-based CRM Security in Changing Organizations

Post Author: Joe D365 |

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!

How to Create a Team-based Security Model

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:

  • Basic - Primarily readers of CRM records; may also append records and append to other records.
  • Super - Primarily creators and editors of CRM records. Responsible for data entry and/or data governance.
  • Executive - Senior leadership who needs broad access to records across the organization.

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:

  • Administration – Basic
  • Administration – Super
  • Administration – Executive
  • Customer Service – Basic
  • Customer Service - Super
  • Sales – Basic
  • Sales – Super

 

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:

  • Adding and removing security roles from a team it the team's core business function changes.
  • Adding and removing users from teams if individuals' core business functions change within the organization. Keep in mind users can be assigned to multiple teams if the user's business functions are varied and blended across departments.
  • Creating new teams and assigning the right security roles to them when new departments are formed.
  • If you use team-based security, best practice is to administer all user permissions this way, even if a team consists of just one user. This will reduce the confusion of remembering which users have security roles assigned directly to the user record, and which users are assigned to teams that hold the security roles.
  • As you add new entities to your CRM solution, don't forget to create the Read/Append and Create/Edit security roles for them, and assign them to the right teams.

Team-based security can take the pain out of CRM administration in a fast-changing organization. Go forth and administer!

Happy CRM'ing!

 

Joe CRM
By Joe D365
Joe D365 is a Microsoft Dynamics 365 superhero who runs on pure Dynamics adrenaline. As the face of PowerObjects, Joe D365’s mission is to reveal innovative ways to use Dynamics 365 and bring the application to more businesses and organizations around the world.

One comment on “Administering Team-based CRM Security in Changing Organizations”

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

PowerObjects Recommends