Building a permission set group is mechanically simple but architecturally consequential. The bundle composition decides what every assigned user can do, and changes propagate across the user base. Plan the bundle around a specific role, test against representative users in sandbox, and document the rationale before deploying. Permission changes touch security, and security changes need traceability.
- Identify the role and audit existing permission sets
Map the target role (Sales Manager, Service Tier 2, Marketing Operator) to the permission sets that grant the capabilities the role needs. List the existing permission sets and confirm each one is current. If permissions are scattered across legacy profiles, plan to migrate them first.
- Create the permission set group
Setup > Permission Set Groups > New. Enter a label and API name that describes the role, like PSG_Sales_Manager. Add a description that explains the intended audience and any constraints (only assign during business-hour windows, requires manager approval, etc.).
- Add component permission sets
From the group detail page, click Permission Sets in Group > Add Permission Set. Pick the permission sets that belong in the bundle. Use existing permission sets wherever possible; create new ones only when no existing set fits the capability.
- Mute any permissions that should not transfer
Click Muting Permission Sets > New Muting Permission Set. Pick the permissions to mute (object access, system permission, app permission). Muting suppresses the permission within this group only, leaving the source permission set untouched for other consumers.
- Save the group and wait for the recalculation
Salesforce automatically recalculates the effective permissions for every user in the group. The job runs in the background and is usually fast. The detail page shows the recalculation status; refresh until it shows Updated.
- Assign the group to test users in sandbox
Setup > Users > pick a test user > Permission Set Group Assignments > Edit Assignments > add the group. Log in as the user to confirm every expected capability works and no unexpected access leaks through.
- Deploy to production and assign to real users
Deploy via change set or metadata API. Assign to real users either through manual edits, mass assignment via Data Loader, or via Flow automation that grants the group based on role or job-title field values.
- Build the access-review dashboard
Build a report grouped by Permission Set Group, with user count, last-login date, and assignment expiration. Schedule a quarterly access review with the security team to catch over-permissioned users and stale assignments.
The permission sets bundled into the group. Users inherit every permission from every included set, unless muted.
Optional sets that suppress specific permissions the bundled sets grant. Provides fine-grained exclusion without forking permission sets.
Optional date when the group assignment auto-removes. Critical for contractors, temporary access, and project-bound elevation.
- Permission set group changes trigger a recalculation job. Users may see the old permissions for a few minutes after the group is updated, especially in large orgs with many group members.
- Muting permissions removes them only within the group; the source permission set is unchanged. Muting is the right pattern for role-specific exclusion, not for permanently removing a permission.
- Profiles are slowly being retired. Build new permission management on permission set groups, not profiles. Legacy profile permissions will keep working but new feature work increasingly assumes permission set groups.
- Assignment expirations auto-remove the group but do not auto-restore prior assignments. If you expire a temporary elevation, plan how the user returns to their baseline access before the expiration triggers.
- Permission set group composition can drift over time as new permission sets are added without review. Schedule a quarterly audit to catch over-permissioned bundles before they become audit findings.