A public group is a named, reusable collection of users that you can use anywhere Salesforce accepts a group of users — most importantly as the target of a sharing rule or manual share. A public group can contain individual users, roles, “roles and subordinates,” “roles and internal subordinates,” and other public groups (nested). That nesting is the property that makes public groups the most flexible grouping primitive in Salesforce sharing.
What goes inside a public group
Members can be any combination of:
- Users — individuals by name.
- Roles — every user assigned that role.
- Roles and Subordinates — that role plus everyone below in the hierarchy.
- Roles and Internal Subordinates — same, but excludes external community/portal users.
- Public Groups — other public groups (nesting allowed).
- Portal Roles / Portal Roles and Subordinates (when configured for partner/customer communities).
- Territories (when Enterprise Territory Management is enabled).
- Customer Portal Users / Partner Users (broad license-based selections).
Where public groups get used
| Use case | What the group does |
|---|---|
| Sharing rules | Target of an owner-based or criteria-based share — every member gets the share grant |
| Manual sharing | Share a single record to a group of users at once |
| List view sharing | Restrict who can see/edit a list view |
| Folder access | Reports, dashboards, and email-template folders can be shared with a group |
| Apex sharing | The UserOrGroupId on a share row can be a public group |
| Content libraries | Library membership can be granted to a group |
| Chatter feeds, recommendations, etc. | Audience selection for posts and recommendations |
A public group can’t be used as a record owner — only users and queues own records. Public groups are for sharing access, not for assignment.
Why public groups beat ad-hoc lists
The alternative would be to share records or list views with each user individually. That doesn’t scale and creates audit nightmares. With a public group:
- Add or remove members in one place; every dependent sharing rule, list view, and folder picks up the change automatically.
- Nest groups so larger groupings (e.g., “All Sales”) can contain smaller ones (“Sales EMEA”, “Sales NA”) without duplicating membership.
- Onboard a new employee by adding them to the right groups — no need to update every sharing rule.
Public group vs queue — common confusion
Queues look similar but are functionally different:
- Queues own records (records can have a queue as
OwnerId) and are the assignment target for assignment rules. Members of a queue can claim records from it. - Public groups do not own records. They are pure grouping for sharing/visibility.
See the queue vs public group question for a deeper comparison.
Common interview follow-ups
- Can I share a record to a public group? Yes — both via sharing rule and manual sharing.
- Is there a limit on how many public groups? Practical limits are very high — orgs routinely have hundreds. The relevant cap is usually on how many sharing rules use the group, not the group count itself.
- Can I see who’s effectively in a nested group? Yes — “View Membership” on the group expands the full membership including nested groups, roles, and subordinates.
- What about Grant Access Using Hierarchies? Public groups have a checkbox: “Grant Access Using Hierarchies.” When on, sharing through the group also grants access to users above the group’s members in the hierarchy. Usually off for groups that intentionally exclude managers.
Verified against: Salesforce Help — Public Groups and Sharing & Visibility Architect resources. Last reviewed 2026-05-17.