Permission Sets are atomic. You build one per capability — "Can Export Reports", "Can Approve Discounts", "Can Edit Closed Opportunities" — and assign them to users.
A Permission Set Group bundles multiple permission sets into a single assignable unit, intended to model a job function. Instead of assigning a Sales Manager user 8 separate permission sets, you create a Sales Manager permission set group containing those 8, and assign just the group.
Two features make groups more than a list:
- Calculated permissions — Salesforce computes the union of all included permission sets and the group itself, so user permission checks stay fast at runtime.
- Muting permission sets — within a group you can attach a muting permission set that removes specific permissions otherwise granted by the included sets. This lets you start from a broad bundle and selectively narrow it down — useful when one role needs almost everything in another role's group except for one or two sensitive permissions.
Use a permission set group when you have a recognisable job function (Sales Rep, Sales Manager, Service Agent) and you want one assignment instead of many. Use individual permission sets when permissions are crosscutting and don't map to a single role — like a Beta User set that anyone might temporarily get.
A common mistake is trying to model role hierarchy in permission set groups — they're for permissions, not for record visibility. Roles still own that.