The Swiss Army Knife of Sharing

Module 1 of 6 in the chapter Public Groups and Criteria-Based Sharing Rules, chapter 7 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: What is a public group, and how do you design public groups so one sharing rule does the work of fifty?

Chapter 6 locked the file cabinets: the org-wide defaults, the owner, the role hierarchy. Now we start opening them up, and the first thing I teach next is this. There is a superpower in here, and it is called a public group.

A public group is a named list of who: some users, some roles, even other groups. An admin creates it in Setup, and it has no records of its own. You point things at it.

Here’s an example. The West sales team needs to see every account in the West region. The team is two roles, a regional manager and a few people on loan from other teams. You could share with each of them, one rule at a time. Or you create one public group called West Sales, put those two roles and those people in it, and point one sharing rule at the group. Next month, when a new team joins the West, you add them to the group. The rule never changes.

That’s why I call the public group the Swiss Army knife of sharing: one tool that does many jobs.

Chapter 5 introduced it on the map: a group can hold users, roles and other groups, and it has a hierarchy checkbox of its own. This module designs with it.

A group is a bucket, and a bucket grants nothing

Here’s the first thing to get straight. “Group membership alone doesn’t provide data access” (Platform Sharing Architecture (opens in a new tab), Salesforce Architects, checked 2026-11-07). Putting someone in a group gives them nothing. The group is a bucket. Access comes when something shares to the bucket: a sharing rule, a manual share, or code.

And it isn’t only records. Salesforce lists where a public group is used: to set up sharing access through a sharing rule, to share records manually, to give access to report and dashboard folders, to share list views, to add users to a Salesforce CRM Content library, and to assign users to actions in Salesforce Knowledge (Public and Personal Groups (opens in a new tab), Salesforce Help, checked 2026-11-07). So one group can decide who sees a set of records, a folder of reports and a list view. Keep that in mind when you change it.

What goes in the bucket

“A group can contain individual users, other groups, or the users in a particular role or territory.” It can also hold a role or territory together with all the users below it in the hierarchy (Public and Personal Groups).

• Users. Straightforward. People move, though, and every move is a change to the bucket (more on that below).
• Other groups. Groups can contain groups can contain groups. An Arizona group, a California group and a Nevada group, and an all-US group that holds all of them. Share with whichever level you need.
• A role. Everyone in that role.
• A role and the roles below it. Say I want to share some records with a VP, but they have support staff. The people do the work. A record only the VP can see doesn’t help anyone. So you add the role with its subordinates, and the access flows down to the team.

Watch the names in that last one, because they changed. Salesforce now lists Roles and Subordinates as “Deprecated. Use Roles and Internal Subordinates instead” (Group Member Types (opens in a new tab), Salesforce Help, checked 2026-11-07). Roles, Internal and Portal Subordinates includes site and portal users too. And there’s a warning for older orgs: in orgs created before February 8, 2024 that enabled digital experiences before Winter ‘26, Roles and Subordinates members “are converted to Roles, Internal and Portal Subordinates members.” Review those groups, and use Roles and Internal Subordinates where you mean only your own people (same page). External users in groups are Part 3.

Two kinds of people can’t go in a public group at all: unauthenticated guest users and high-volume site users (Public Group Considerations (opens in a new tab), Salesforce Help, checked 2026-11-07; Group Member Types).

And don’t double up. If a group has a manager’s role and also that manager’s role with its subordinates, the first one is redundant. The bigger one supersedes it.

One rule, one group, then change the group

Here’s why I call it a Swiss Army knife. When a sharing rule targets a group, you can put almost anything into that group. A person, a role, a role and its subordinates, another group, a territory. That one sharing rule can share with many places.

If you shared with a role, then wanted another role, then another, you’d be creating duplicate sharing rules. Instead, you create one sharing rule, target a group, and next month you add other groups to it, and now they all get access.

Salesforce gives the same advice: when you need to share the same records with sales reps in several regions, each with its own role, plus a few individual users, “Instead of creating separate sharing rules, you can create one public group with all of these roles and the individual user added that serves as the sharing rule target” (Public and Personal Groups).

Click to enlarge

Now the other side of that power. Whoever can change the group can change who sees the records, without touching the rule. Only administrators and delegated administrators can create and edit public groups, and you can name delegated administration groups whose members “can add or remove members from this public group” (Create and Edit Public Groups (opens in a new tab), Salesforce Help, checked 2026-11-07). Decide who those people are. And every edit costs something: “When you edit groups, roles, and territories, sharing rules are recalculated to add or remove access as needed” (same page). Chapter 6, module 1 showed where that work happens.

To see what a group opens before you change it, use its access summary: it shows “the sharing rules, report and dashboard folders, and list views where this public group is used to grant access,” and the other groups it’s in (Public and Personal Groups).

The group’s own hierarchy switch

There’s a little superpower hidden in the group. A public group can grant access using the hierarchies too. You could have the object’s checkbox unchecked and this one checked. People don’t even realize it’s there.

When it’s selected, “any records shared with users in this group are also shared with users higher in the hierarchy” (Create and Edit Public Groups). So the managers above every member get what the group gets. Salesforce says when to leave it off:

• “Deselect Grant Access Using Hierarchies if you’re creating a public group with All Internal Users as members, which optimizes performance” (Create and Edit Public Groups).
• “For performance reasons, it’s also recommended that you keep this option disabled if users above the public group members don’t need access to records shared with the group” (Public Group Considerations).

It also matters for confidential data. With the switch off, records shared to the group stay with its members, and Salesforce describes groups where “the data will be accessible ONLY to group members, and nobody else in the organization” (Platform Sharing Architecture). That’s about what you share to the group. The owner and the owner’s managers keep their own access, as chapter 6, module 5 showed.

So start with it off, and turn it on only when the managers above the members really need what the group gets.

Keep the buckets healthy

Salesforce’s guidance for groups in big orgs (Public Group Considerations):

• “Create a group when at least a few users need the same access.”
• “Create a group for members who don’t need to frequently move in or out of the groups.” Every move is a recalculation.
• “Avoid creating groups within groups that result in more than five levels of nesting.” Groups in groups is the superpower; five levels is the edge of it.
• Above 10,000 members, editing membership on the group’s own page can cause “performance issues or group members being deleted.” Use the access summary, user access policies or the GroupMember API instead.

Two other kinds of group

Personal groups. “Each user can create groups for their personal use in manual shares.” They’re a shortcut for one person’s manual sharing, not a design tool, and “Personal groups are available only in Salesforce Classic” (Public and Personal Groups).

Manager groups. These are the surprise. Chapter 6, module 4 said the role hierarchy has nothing to do with the Manager field on the user. Manager groups are where the Manager field comes back. “Every user has two manager groups”: the Managers Group, the user’s “direct and indirect managers,” and the Manager Subordinates Group, the user “and the user’s direct and indirect reports.” Turn them on in Sharing Settings, under Other Settings. They’re share targets, used “via manual sharing, sharing rules, and Apex managed sharing,” but “they can’t be added to other groups and don’t include site or portal users” (Sharing Records with Manager Groups (opens in a new tab), Salesforce Help, checked 2026-11-07).

Salesforce’s example fits chapter 6 well: a custom object for performance reviews, Private, with Grant Access Using Hierarchies turned off, so only the employee sees their own review. Then a sharing rule shares each review to the owner’s Managers Group (same page). The review goes up the management chain, not up the role hierarchy. That’s the right answer when the people who manage a person aren’t the people above their role. Once a rule uses them, you can’t turn manager groups off again (same page).

Click to enlarge

What an architect decides here

• Which buckets the org needs, named for the access they stand for, not for the people in them today.
• What goes in each one: roles and their subordinates, other groups, territories, and as few named users as possible.
• Where existing groups use Roles, Internal and Portal Subordinates, whether they should be Roles and Internal Subordinates.
• For each group, whether Grant Access Using Hierarchies is on, and why.
• Who may change each group’s membership, including delegated administration groups.
• Nesting kept to five levels or fewer; big groups managed through the access summary or the API.
• Whether manager groups are needed, where the management chain isn’t the role hierarchy.

Beyond the exam: what AI changes. Salesforce’s own Help suggests asking the Setup agent to do this work: “Create a public group that has Grant Access Using Hierarchies disabled” (Create and Edit Public Groups). That’s useful, and it’s a sharing change, made by a sentence. Before an agent adds a role, a group or a person to a bucket, check what the bucket opens: its access summary lists the rules, folders and list views. And when an agent’s own user goes into a group, it gets everything the group gets.

Explore

• Public and Personal Groups (opens in a new tab), Salesforce Help (checked 2026-11-07)
• Create and Edit Public Groups (opens in a new tab), Salesforce Help (checked 2026-11-07)
• Public Group Considerations (opens in a new tab), Salesforce Help (checked 2026-11-07)
• Group Member Types (opens in a new tab), Salesforce Help (checked 2026-11-07)
• Sharing Records with Manager Groups (opens in a new tab), Salesforce Help (checked 2026-11-07)
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (checked 2026-11-07): section Public Groups