Group
A Group in Salesforce is a named collection of users, used as a single addressable unit for sharing records, granting permissions, queuing work, and routing automation.
Definition
A Group in Salesforce is a named collection of users, used as a single addressable unit for sharing records, granting permissions, queuing work, and routing automation. The platform supports three types of groups: Public Groups (admin-defined, available to share rules and sharing-button assignments), Personal Groups (user-defined, available only to the user who created them), and Roles + Subordinates (an automatically-managed virtual group based on the role hierarchy). Chatter also introduces a separate Chatter Group concept used for collaboration feeds, which is a different object and not the same as the Public Group described here.
Public Groups are the workhorse: admins create them under Setup, Public Groups, add member users by username, role, or role + subordinates, and reference the group from sharing rules, record-level sharing, queues, list views, and email alerts. Groups can be nested (a group can include another group as a member), which lets admins build reusable user collections without re-listing the same users in every sharing rule. The Group standard object exposes the membership via SOQL, making automation and bulk audit straightforward.
The four Group flavors that get mixed up in conversations
Public Groups for sharing rules and queue assignment
Public Groups are admin-defined collections of users. Setup, Public Groups, lets you create a group, name it, and add members by user, role, role + subordinates, public group, customer portal user, or partner user. Once created, the group appears in sharing rule targets, in queue member configuration, in record-sharing manual additions, and in many other Setup pickers that need a multi-user target. Public Groups are the primary user-collection abstraction the platform offers.
Personal Groups created by individual users
Personal Groups are user-defined groups visible only to the user who created them. Reps create them via Personal Setup to share specific records with a handful of trusted colleagues without involving the admin. Personal Groups appear only in the creator''s sharing dropdowns. The feature is lightly used in most modern orgs because Public Groups and manual shares cover the common cases.
Role and Role-and-Subordinates virtual groups
Every role in the role hierarchy automatically gets two virtual groups: Role and Role + Subordinates. The Role group contains every user assigned that exact role; the Role + Subordinates group contains the role plus every role beneath it in the hierarchy. These virtual groups can be used in sharing rules and queue membership the same way Public Groups can. They auto-update when users are added, removed, or moved between roles.
Chatter Groups for collaboration
Chatter Groups are a separate construct stored in the CollaborationGroup standard object. They exist for collaboration feeds: a group has its own feed, member list, file library, and Following status. Chatter Groups can be Public, Private, or Unlisted, and can include external users when Communities are enabled. They are not the same as Public Groups for sharing; the two have different objects, different APIs, and different purposes.
Nesting and audit
Public Groups can contain other Public Groups. Nesting is the antidote to maintaining the same user list in five sharing rules; create one Group, nest it inside the higher-level Groups, and update membership in one place. The GroupMember standard object exposes the relationships via SOQL, which is useful for auditing who actually has access through nested chains.
Groups in queue configuration
Queues, the work-distribution feature for Cases, Leads, and custom objects, accept Public Groups as members. Adding a group as a queue member effectively delegates ownership of queued records to every user in the group. Combine with omni-channel routing or list-view-based pickup to build a team-owned work queue without re-listing users per object.
Sharing settings interaction
Groups become powerful when paired with sharing rules and the org-wide default setting. With OWD set to Private and a sharing rule granting Read/Write access to a Public Group, every group member sees and edits records that meet the rule''s criteria. Removing a user from the group revokes that access on the next sharing-rule recalculation, which can take minutes for large data sets.
Create a Public Group and use it in a sharing rule
The end-to-end loop for granting team access via a group is a 10-minute Setup task once the use case is clear.
- Open Setup, Public Groups
Setup, Quick Find, type Public Groups, click the result. The page lists every existing group with edit and delete actions.
- Click New Group
Enter a Label (user-facing name) and Group Name (API name). The Group Name should be descriptive; future admins reference it in sharing rules by name.
- Add members
Use the Search dropdown to pick Users, Roles, Roles and Subordinates, Public Groups, or Portal-related options. Add the relevant members to the group.
- Set Grant Access Using Hierarchies
Check the box if managers above each member should also get access through the group. Most modern orgs leave it unchecked to keep sharing intentional.
- Save and reference in a sharing rule
Save the group. Open the relevant object''s sharing settings, create a sharing rule targeting the new group with the desired access level.
- Verify access by impersonation
Log in as a group member and confirm the expected records are visible at the granted level. Sharing-rule recalculation can take minutes for large data sets.
User-facing name shown in pickers.
API name referenced by metadata and SOQL.
Users, roles, groups, or portal users that belong to the group.
Boolean controlling whether the role tree above members also inherits the group''s access.
- Chatter Groups and Public Groups are different objects (CollaborationGroup vs. Group). Documentation and admins frequently conflate them; pick the right one before configuring.
- Removing a user from a Public Group revokes their group-granted access on the next sharing-rule recalculation, which is asynchronous and can take a while.
- Personal Groups are not visible to admins or to other users. Audit them by querying the Group object filtered on Type = ''Regular'' and OwnerId IS NOT NULL.
- Roles + Subordinates groups update automatically as the role hierarchy changes, which is convenient but means a role move can silently grant access to a different population.
Trust & references
Cross-checked against the following references.
- Create and Edit Public GroupsSalesforce Help
- Group Types OverviewSalesforce Help
Straight from the source - Salesforce's reference material on Group.
- Group Standard ObjectSalesforce Developers
- GroupMember Standard ObjectSalesforce Developers
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 Chatter Group?
Q2. What visibility types do groups support?
Q3. What's a different meaning of 'group' in Salesforce?
Discussion
Loading discussion…