Public Group
A Public Group in Salesforce is an arbitrary collection of users used as a single sharing or access target.
Definition
A Public Group in Salesforce is an arbitrary collection of users used as a single sharing or access target. Where Role Hierarchy models the formal chain of command and Account Teams model per-record collaboration, Public Groups model anything that does not fit either pattern: a cross-functional Compliance Review group spanning Legal, Finance, and Sales Ops; a Strategic Accounts team spanning AEs from three regions; a Vertical Specialists group spanning sales and service users who all work the Healthcare segment. The Public Group has a Name and a Description, plus a membership list.
Public Groups exist because real organizations rarely fit a clean tree. A Salesforce admin can model the org chart through Role Hierarchy, but the org chart describes who reports to whom, not who needs access to what. The actual access patterns in any large company are full of cross-cutting relationships that the hierarchy does not capture. Public Groups let you express those relationships explicitly, then use them as the target of Sharing Rules, List View visibility, Report and Dashboard folder sharing, Manual Sharing, and a handful of other places that need to grant access to a defined set of users.
How Public Groups model cross-cutting access patterns
Members and nesting
A Public Group can contain Users (specific individuals), Roles (everyone in a specific Role), Roles and Subordinates (everyone in a Role plus everyone in any Role that reports to it), and other Public Groups. The nesting lets you compose groups: a "All EMEA Sales" group might contain three child groups (EMEA Enterprise Sales, EMEA Commercial Sales, EMEA SMB Sales), each of which contains the relevant Roles or Roles-and-Subordinates. Nesting one level deep is common; nesting three or four levels deep starts to confuse audit reports and the Setup UI both. Keep the nesting shallow.
Public Groups as sharing targets
The most common use of Public Groups is as the target of Sharing Rules. A criteria-based Sharing Rule like "Accounts where Industry = Healthcare share with the Healthcare Vertical Group" needs the Healthcare Vertical Group to exist as a Public Group first. Owner-based Sharing Rules use Public Groups on both sides: "records owned by the EMEA Sales group share with the EMEA Finance group." Most enterprise orgs have between thirty and a hundred Public Groups, each one a sharing target for one or more Sharing Rules, and the structure tends to mirror how the company actually collaborates rather than how the org chart looks.
Grant Access Using Hierarchies toggle
Every Public Group has a Grant Access Using Hierarchies checkbox. When checked (the default), users in any Role above the explicit group members also get access through the group, because the Role Hierarchy propagates access upward. When unchecked, only the explicit members get access; Role Hierarchy is bypassed. Most orgs leave this checked because the Role Hierarchy propagation matches their access intent, but some compliance scenarios need it off to prevent senior managers from seeing records they were not explicitly granted. The toggle is easy to miss in audits because it lives on the Public Group itself, not on the Sharing Rule that uses it.
Public Groups vs Roles
Roles and Public Groups serve different purposes that confuse newer admins. A Role is one user's place in the hierarchy; a Public Group is an arbitrary collection of users for sharing. A user has one Role but can be in many Public Groups. Roles propagate access upward through the hierarchy; Public Groups propagate access only to explicit members (plus hierarchy-upward if the toggle is on). Use Roles to model reporting structure; use Public Groups to model anything else. The two systems do interact in Sharing Rule targets, where Roles, Roles-and-Subordinates, and Public Groups are all valid choices, but the underlying concept is distinct.
Folder and report sharing
Public Groups are also the target for sharing report folders, dashboard folders, and document folders. A reports folder shared with a Public Group means every member of the group can see the reports inside it. The folder-sharing UI uses Public Groups as a primary mechanism, so building Public Groups for report-audience patterns (Executive Reports, Manager Reports, Rep Reports) is the standard practice in any reporting-heavy org. The same applies to List View sharing for Accounts, Opportunities, and Cases; List Views can be visible to All Users, to a Role, or to a Public Group, and Public Groups are the most-used path for cross-team list view sharing.
Auditing Public Group membership
Public Group membership is fluid because admins add and remove users frequently. Auditing who is in each Public Group at any moment is straightforward through Setup > Public Groups, but the cumulative effect (what records does this user see because of all their Public Group memberships) is harder. The standard pattern is to query the User and Group relationships through the API (Group, GroupMember, UserRecordAccess) and produce a report of effective access. Quarterly access reviews should include Public Group membership; orgs that never audit it accumulate members who joined a group for a one-off project and never got removed.
Performance and limits
There is no hard limit on Public Group count in most Salesforce editions, but practical limits emerge from the underlying sharing performance. Each Public Group that drives Sharing Rules adds rows to ObjectShare tables on records that match those rules. Highly nested Public Groups (groups containing groups containing groups) slow down sharing recalculation noticeably, because the platform has to expand the membership during evaluation. Keep nesting depth under three levels for performance reasons and audit clarity.
How to create a Public Group
Creating a Public Group is one of the most-done sharing configurations in any growing Salesforce org. The configuration is simple; the design decision (who exactly should be in this group, and why) matters more than the click path.
- Open Setup and navigate to Public Groups
Setup > Users > Public Groups. The list shows every existing Public Group with the member count.
- Click New
The New button at the top opens the group editor. Pick a clear Group Label and an API Name that reflects the group's purpose.
- Add members
Use the dual-pane Available Members / Selected Members UI to add Users, Roles, Roles and Subordinates, or other Public Groups. Most groups end up combining several membership types; pick the smallest combination that captures the intended audience.
- Configure Grant Access Using Hierarchies
Tick or untick based on whether Role Hierarchy should propagate access through the group. Default is on. Untick only when compliance requires flat group membership.
- Save
Click Save. The group is immediately usable as a sharing target.
- Wire the group into Sharing Rules and folder sharing
The group itself does nothing until something references it. Build the Sharing Rule, Folder Share, or List View Share that uses the group as a target.
- Test with representative members
Confirm that the users in the group can see what they should and that users outside the group cannot see records that were supposed to be group-restricted.
- Public Groups with nested groups can be hard to audit. Keep nesting shallow (one or two levels) for clarity.
- Grant Access Using Hierarchies defaults to on. Forgetting to disable it on compliance-sensitive groups can leak access to senior managers who were not explicitly intended to see records.
- Public Group membership tends to accumulate. Audit quarterly and remove members who no longer need access.
- Public Groups cannot have Group as a member on certain types (e.g., Queue groups behave differently from Public Groups). Confirm the group type matches your use case.
Trust & references
Cross-checked against the following references.
- Public GroupsSalesforce Help
- Sharing RulesSalesforce Help
Straight from the source - Salesforce's reference material on Public Group.
- Public GroupsSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Public Group?
Q2. Where can public groups be referenced?
Q3. Why use public groups?
Discussion
Loading discussion…