Group Member
A Group Member in Salesforce is a row in the GroupMember object that links a user, role, or other group to a Public Group, Queue, or other group container.
Definition
A Group Member in Salesforce is a row in the GroupMember object that links a user, role, or other group to a Public Group, Queue, or other group container. Each GroupMember row represents one membership relationship: GroupId points to the parent group, UserOrGroupId points to the included user or sub-group. The object is the platform's central registry of group composition, queryable through SOQL and editable through Setup, Data Loader, and APIs.
Group membership underpins much of the access control model. Public Groups grant folder access, list view sharing, queue ownership, and manual record sharing. Roles and the role hierarchy use a similar but distinct membership concept. Understanding the GroupMember object is the path to programmatic membership management: bulk-adding users to a group through Data Loader, automating membership based on a custom field, or auditing who is in which group across the org.
How Group Member works in Salesforce
GroupMember object structure
GroupMember has three primary fields. GroupId points to the parent group (Public Group, Queue, role-and-subordinates pseudo-group, or other system group). UserOrGroupId points to the included entity (a User Id, another Group Id for nested groups). SystemModstamp tracks the last membership change. The object is read-only for system groups (role hierarchies, all-internal-users) but editable for Public Groups and Queues through standard tooling.
Public Groups versus Queues
Public Groups are general-purpose containers used in sharing rules, folder permissions, and manual record sharing. Queues are also groups but with the specific purpose of holding records pending assignment (Case queues, Lead queues, custom object queues). Both are represented in the Group object and their members in GroupMember; the Type field on Group distinguishes them. Queries against GroupMember return both types unless filtered.
Nested groups
Public Groups can contain other groups. A parent group with a child group automatically includes every member of the child. The platform resolves nested membership at access-time, so adding a user to the child group immediately grants them access wherever the parent group is referenced. Nesting simplifies maintenance: rather than updating multiple groups when a user joins, update the smallest group and the change cascades.
Role-based pseudo-groups
Some groups exist conceptually but not as Group records you can edit directly. Role-and-Subordinates groups represent every user in a role plus everyone below in the hierarchy. They appear in Group queries with Type = Role or RoleAndSubordinates, but their membership is computed from the UserRole table rather than from GroupMember rows. You can grant access to these pseudo-groups in sharing rules; you cannot manually add users to them.
Bulk membership management
Adding hundreds of users to a group through the standard UI is impractical. Data Loader against GroupMember is the standard approach: export current membership, modify the list, upsert back. The operation is fast and idempotent (re-inserting an existing membership is a no-op). For programmatic maintenance, an Apex batch can manage group membership in response to user attribute changes.
Auditing group composition
Use SOQL to audit: SELECT Group.Name, COUNT(Id) FROM GroupMember GROUP BY Group.Name returns the size of every group. For specific group membership, SELECT UserOrGroupId FROM GroupMember WHERE GroupId = '<id>' lists the members. Quarterly audits catch groups that accumulated stale members; over time, groups can balloon to hundreds of users, most no longer needing the access the group grants.
Permission considerations
Modifying GroupMember requires the Manage Public Groups permission for Public Groups, or Manage Internal Users for Queues. Standard users without these permissions cannot edit group membership, even for groups they own. Audit who has these permissions; over-permissive assignment lets users adjust their own group membership to gain unintended access.
Manage group membership
Managing group membership involves both the standard UI for small changes and Data Loader for bulk operations. The steps below cover both paths plus the audit workflow that keeps groups clean.
- Identify the group
Setup > Public Groups or Setup > Queues. Find the target group. Note the Group Id for SOQL or Data Loader operations.
- Add individual member through UI
Edit the group, search for the user or sub-group in the Selected Members area, save. The change is immediate.
- Bulk add through Data Loader
Export current GroupMember rows for the group. Prepare a CSV with GroupId and UserOrGroupId for new members. Insert via Data Loader. Confirm row count matches expectations.
- Verify access
Use Login As to impersonate a new member. Confirm they have the access the group grants (folder visibility, record sharing, queue ownership).
- Document group purpose
For each group, capture the purpose, the membership criteria, and the access it grants in a wiki or spreadsheet. Without documentation, future admins inherit a black box.
- Audit quarterly
Run SELECT Group.Name, COUNT(Id) FROM GroupMember GROUP BY Group.Name. Identify oversized groups for review. Confirm each member still needs the access.
- Remove stale members
For users no longer needing access, remove through the UI for small changes or Data Loader delete for bulk. Deactivated users do not need group removal; they cannot access the org regardless.
Single user added to the group. The most common operation.
Another group added as a sub-group. Cascading membership; useful for shared organizational structures.
A role added. All users with that role inherit the group access.
Role plus everyone below in the hierarchy. Common for management-level group inclusion.
Insert or delete GroupMember rows in bulk. The only practical path for hundreds of changes.
- Role-and-Subordinates groups are not editable directly; membership comes from the UserRole table. Manual edits fail.
- Nested groups cascade at access time. Adding a user to a deeply nested child group can grant unexpected access through multiple parent references.
- Manage Public Groups permission is sensitive. Over-permissive assignment lets users grant themselves access. Audit the permission set assignments.
- Deactivated users remain as GroupMember rows. Cleanup is cosmetic; the deactivated user cannot access the org regardless.
- Bulk delete through Data Loader is irreversible. Test with a small batch and confirm impact before processing thousands of removals.
Trust & references
Straight from the source - Salesforce's reference material on Group Member.
- GroupMember in Object Reference for the Salesforce PlatformSalesforce Developer Documentation
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.
Discussion
Loading discussion…