Group Member
A Group Member in Salesforce (GroupMember in the API) is a standard junction object that records a single membership relationship between a Group and either a User or another Group.
Definition
A Group Member in Salesforce (GroupMember in the API) is a standard junction object that records a single membership relationship between a Group and either a User or another Group. Each Group Member record holds a GroupId (the parent Group — Public Group, Queue, Chatter Group, or any other system-managed group), a UserOrGroupId (the polymorphic member reference, pointing to either a User or another Group), and standard system fields. Groups in Salesforce are nestable — a Public Group can contain other Public Groups as members, and Group Member captures each level of that nesting one row at a time. Group Member is the underlying data structure behind nearly every group-based Salesforce feature: Public Group sharing rules iterate over Group Members to determine record visibility; Queue assignment routes records to Group Members; Chatter Group membership controls who can post and read; folder-access lists evaluate against Group Members. Every "who is in this Group?" question in Salesforce ultimately resolves to a Group Member SOQL query.
In plain English
“A Group Member is one membership record — like one user's name on a Group's roster. Add a User or another Group to any Salesforce Group (Public Group, Queue, Chatter Group), and a Group Member record is created. Querying Group Member is how you ask "who is in this Group?" in SOQL.”
Worked example
A Salesforce admin creates a new Public Group called "Western Region Sales" and adds 25 sales reps as members. Salesforce inserts 25 Group Member records, each with GroupId pointing to Western Region Sales and UserOrGroupId pointing to one rep's User Id. The admin then creates a parent Public Group called "All Sales" and nests Western Region Sales (along with Eastern Region Sales and Central Region Sales) into it as Group Members. A sharing rule is configured to grant Read access on all Opportunities to All Sales — Salesforce traverses the Group Member hierarchy: All Sales → 3 child regional Groups → 75 individual sales reps, each of whom inherits the sharing access. When a new rep joins Western Region, the admin only needs to add one Group Member row, and the All Sales access cascades automatically.
Why Group Member matters
The UserOrGroupId field is polymorphic and accepts either a User Id or a Group Id. Querying which Users belong to a given Group requires either a single SOQL query traversing both options (with type-aware filtering) or two separate queries — one for direct User membership and one for nested Group membership, recursively expanding until all leaf Users are reached. For deeply nested group hierarchies, computing effective membership is a multi-query operation that Salesforce caches internally for performance.
Group Member rows for system-managed groups (Roles, Role-and-Subordinates, Territory) are managed by the platform, not by admins. When an admin assigns a User to a Role through Setup, Salesforce automatically maintains the corresponding Group Member rows for the Role's Public Group representations. Direct Group Member inserts on system-managed groups frequently fail validation — these groups should be modified through their owning feature (Role, Territory) rather than through Group Member directly.
Group Member is the foundation of nearly every Salesforce sharing-related feature. Public Groups, Queues, Chatter Groups, Roles (which auto-generate Public Groups), and Territory all use Group Member as their underlying membership store. Listing all the Groups a single User belongs to is a common admin troubleshooting query — SELECT Group.Name FROM GroupMember WHERE UserOrGroupId = :userId — and is often the first step in diagnosing unexpected record visibility.
How organizations use Group Member
Maintains nested Public Groups for Region > Sub-Region > Team, each with Group Members linking up the hierarchy. Sharing rules grant access at the parent Region level, with the cascade through Group Member rows automatically extending visibility to every sub-team's individual members.
Adds and removes Group Members on Queue groups as agent rosters change shifts. Queue routing reads Group Member to determine which agents can claim a Case, with the platform automatically maintaining ownership transitions when agents leave or new ones join.
Queries Group Member with UserOrGroupId = a specific User to list every Group that User belongs to, including system-managed Role groups. The query is the first step in diagnosing why a user can or cannot see a specific record — Group Member is the connective tissue of the entire sharing model.
Trust & references
Straight from the source — Salesforce's reference material on Group Member.
- GroupMember in Object Reference for the Salesforce PlatformSalesforce Developer Documentation

Discussion
Loading discussion…