Did you know that the Salesforce group membership architecture can help improve the performance of your app? Salesforce engineered its group architecture to enhance the performance of several of its key internal sharing features. Read this blog post to learn why and when you should leverage the Salesforce group architecture as a performance tool, with links to additional information about Salesforce groups and sharing performance.

Salesforce Group Membership Architecture

The Salesforce group membership architecture consists of a few objects that store groups’ names and types, in addition to their members. In order to understand the performance considerations related to using a group membership sharing architecture, let’s first take a step back and understand some basic concepts about how sharing works in Salesforce.

Each object in Salesforce that has its organization-wide default setting configured as Public Read Only or Private will also have an associated share object. Salesforce uses the associated share object to provide access grants to users who would otherwise be restricted by the organization-wide default setting. Every access grant that provides a Salesforce user with access to a restricted object has a record in an associated object share table.

Without the existence of groups, the records in the object share tables would map users to the object that they have access to in a one-to-one relationship. One benefit of the Salesforce group membership architecture is that it adds an additional layer of abstraction.

Because a group is a representation of one or more users who share a single access grant to the associated record, having a group access grant move from one record to another involves maintaining only a single share record for the group, not a share record for every member of that group.

Now that you have a general understanding of how the group architecture works in Salesforce, let’s take a look at the two types of groups.

System-Defined Groups

Even if you don’t use groups in your Salesforce org, they still play a role in enhancing the performance of key internal sharing features. What you may not be aware of is that each of those features shares the same architecture as the public and private groups that you configure within Salesforce.

A little later in this post, you’ll learn how the following internal Salesforce features leverage the group membership architecture in a systematic way:

• role hierarchy
• territory hierarchy
• queues

User-Defined Groups

User-defined groups in Salesforce are groups that directly modify the group membership object. They differ from system-defined groups in that you cannot directly modify system-defined groups.

Salesforce uses the following user-defined groups:

• public groups
• private groups

Enhancing Performance with the Group Sharing Architecture

Without the Salesforce group sharing architecture, every user who was granted access to a restricted record would have to have an associated record in the object share table. Because these tables already have hundreds of millions of records in enterprise organizations, it is important to minimize the number of records to ensure peak performance.

Reducing the number of records in the object share tables is just one way the Salesforce group architecture can increase performance, however. When operations performed in Salesforce cause multiple users to lose or gain visibility to one or more records, the Salesforce group architecture can significantly reduce the maintenance and performance impact of those operations. It does this by adding or removing a single share for the group containing all of the members of that group.

The role hierarchy is a perfect example of an internal feature that leverages the group sharing architecture to enhance performance. When you grant a user at the bottom of the role hierarchy access to a record, Force.com adds a single share to the associated object share table. The group membership architecture that is already in place grants access to all role managers. If the role hierarchy did not leverage the group membership architecture, Force.com would have to add an object share record for every role manager in the role hierarchy. Furthermore, if the role hierarchy structure were changed, it would affect a massive number of object share records, which would in turn radically decrease performance.

Sharing Performance Considerations

Salesforce group membership can significantly increase the performance of many sharing operations, but it is not the answer to every group visibility problem. Groups are intended for situations in which multiple users share the same visibility; from a performance perspective, you generally want to reserve the Salesforce group architecture for situations where you have teams of at least a few users who share the same access. Creating groups for very small numbers of users–or even single users–can negatively affect sharing performance in Salesforce because access checks must traverse additional relationships.

Using the group membership architecture in Salesforce requires another critical consideration that can impact performance and reliability. When users move in and out of Salesforce groups, org-wide group sharing locks are used to ensure that data integrity is maintained within the group hierarchy. This type of lock is exclusive and affects the movement of users in all types of groups, including the role hierarchy, territory hierarchy, queues, public groups, and private groups.

When these types of locks are held, all other group membership operations must wait for the lock to be released, and this delay can cause lock contention in the org. Situations in which an extremely high volume of users are moved between groups via an automated process will scale better when those users are shared directly to the records rather than shared through groups.

See Managing Group Membership Locks for Success to learn more about how to manage group membership locks.

Use Case #1: Strategic Account Marketing Visibility

The “Strategic Account” marketing team needs visibility to all named accounts within Salesforce. Because of the complex logic that determines which accounts are strategic, a trigger has been implemented on the account object to flag the strategic accounts.

The Solution

In this scenario, group membership is the only option that makes sense from both an administrative perspective and a performance perspective. Because the “Strategic Account” marketing team consists of a group of users who share the same visibility of accounts, and users do not frequently move in and out of the group, the group architecture will yield peak performance.

The solution is to implement a group for the strategic account representatives and assign it to each of the strategic accounts. You could implement the method of assignment in a criteria- based sharing rule. By leveraging the Salesforce group architecture, the team can minimize the sharing maintenance required to manage its visibility.

Use Case #2: Territory Management

A large enterprise organization is implementing territory management and will have 20,000 territories. Each territory has a single sales representative, and representatives move very frequently between territories.

The Solution

The choice between using the Salesforce Territory Management feature or another platform technology, such as account teams in Salesforce, is in part a decision about using the Salesforce group sharing architecture. Because the Territory Management feature leverages the group sharing architecture, it has the same performance considerations as as any other architecture which uses group sharing.

Deciding to use the Territory Management feature is an extremely complex process and would not be relevant for this example. However, this example does highlights a use case that is suboptimal for the Territory Management feature. Because each territory has only a single member, and the users move frequently in the territory hierarchy, using the Territory Management feature would increase both the number of relationships to traverse for access checks and the frequency of org-wide group membership locks. Based on this information alone, we would not recommend enabling the Territory Management feature.

The Territory Management feature provides a rich toolset that enables customers to allocate sale responsibilities across their organization.  Many Salesforce customers leverage the Territory Management feature to simplify rule maintenance, enhance performance and drive dynamic sales team visibility.  Determining if the Territory Management feature is right for you includes many other considerations, such as forecasting, rule structure, and rule complexity. You can read more on this in the forthcoming Territory Management Decision Guide white paper.

Summary

By keeping the following core principles in mind, you can ensure that you architect your group sharing to obtain peak performance:

• Moving users from one group to another trigger organization wide group membership locks, so highly dynamic groups can have a negative impact on performance.
• The use case which will provide peak performance includes a group of users who share the same visibility and don’t frequently move from one group to another via an automated process.
• The sharing performance benefit will decrease as the number of group members decreases, and the frequency of user movement within the groups increases.

Related Resources

• About Groups
• Group_Object
• Record-Level Access: Under the Hood
• Designing Record Access for Enterprise Scale
• Managing Group Membership Locks for Success
• Architect Core Resources

About the Author and CCE Technical Enablement

Sean Regan is a member of the Technical Enablement team within the salesforce.com Customer-Centric Engineering group. The team’s mission is to help customers understand how to implement technically sound salesforce.com solutions. Check out all of the resources that this team maintains on the Salesforce Architects website.