Permission Set Groups: The Strategy That Scales

The Problem With Profiles

For years, profiles were the primary permission model. Each user had one profile that granted everything — object access, field-level security, tab visibility, system permissions.

Profiles don’t scale. Every distinct permission bundle becomes a new profile. “Sales Rep - US,” “Sales Rep - EMEA,” “Sales Rep - US with Discount Approval.” You end up with dozens of profiles that differ in tiny ways, and updates mean editing each one.

Salesforce’s direction: minimum profile + permission sets. Assign the smallest profile covering baseline access; grant additional permissions via permission sets.

And for reusable bundles of permission sets: Permission Set Groups.

What a Permission Set Group Is

A Permission Set Group (PSG) is a named container of permission sets. Assigning a user to a PSG is equivalent to assigning them each permission set inside it — but managed as one.

Example: a “Sales Rep Full” PSG might contain:

• Permission Set: Access to Account, Contact, Opportunity objects.
• Permission Set: Discount approval override.
• Permission Set: Salesforce Inbox features.
• Permission Set: Einstein Activity Capture.

Assign the group to a user once; they get all four permission sets.

Why PSGs Beat Individual Permission Set Assignments

Easier user lifecycle. When a user joins the sales team, assign the “Sales Rep” PSG. Removing them from the team removes all four bundled permissions at once.

Less mental load. “Who has discount approval?” is answered by “users in the Sales Rep Full PSG.” Cleaner than “users with discount approval permission set.”

Muting for exceptions. A PSG can include a permission set and then mute specific permissions within it for the group. Use for “almost-this role, but exclude X.”

Versioned role definitions. A PSG’s contents reflect the current role definition. Updating the role updates everyone.

Designing the Permission Landscape

A sound structure:

1. Minimum Profile

Every user starts with a profile that grants only the absolute minimum: login hours, password policy, default UI, minimal object access (no CRUD beyond View on low-sensitivity objects).

The profile is the scaffolding; permission sets are everything else.

2. Building-Block Permission Sets

Create small, focused permission sets for specific capabilities:

• PS_Account_ReadWrite
• PS_Opportunity_ReadWrite
• PS_Discount_Approval
• PS_ExternalApi_Callouts
• PS_Report_Dashboard_Runner

Each set grants one coherent thing. Names are consistent.

3. Permission Set Groups for Roles

Compose building-block sets into PSGs representing business roles:

• PSG_Sales_Rep
• PSG_Sales_Manager
• PSG_Service_Agent
• PSG_Marketing_Ops

A Sales Manager PSG might include the Sales Rep’s permissions plus manager-specific ones — or, more cleanly, be its own composition of building blocks.

4. Assign PSGs to Users

Users get one or more PSGs. No direct permission set assignments for most users — the PSGs cover it.

Muting Permissions

Occasionally a role needs almost the contents of an existing PSG. Instead of creating a whole new PSG:

• Create a muting permission set inside the PSG.
• Specify the permissions to remove.
• Assign the PSG with its muting to the exceptional users.

Example: the standard Sales Manager PSG grants transfer ownership. For a specific region’s managers who shouldn’t have that, mute the transfer permission.

Muting keeps compositions tight without proliferating PSGs.

Naming Conventions

Consistent names save time when your PSG count grows.

• Permission Sets: PS_<Domain>_<Capability> — PS_Case_ReadWrite.
• PSGs: PSG_<Role> — PSG_Sales_Rep.
• Muting sets: MPS_<PSG>_<Reason> — MPS_Sales_Manager_NoTransfer.

Permission Set Licenses

Some permissions require additional licenses — Service Cloud, Marketing Cloud, Einstein add-ons. A permission set requiring a license can only be assigned to users who have that license.

PSGs inherit the license requirements of their contained sets. Assigning a PSG to a user who lacks a required license silently fails to apply the license-gated permissions.

Keep license-gated permission sets separate from license-free ones, and keep PSG compositions aligned to license tiers — e.g., PSG_Service_Agent_Lite (no Einstein) vs. PSG_Service_Agent_Pro (with Einstein).

Auditing Permissions

When “who can do X?” questions arise:

• Field-Level Security Report — who sees a field.
• Permission Set Users view — which users have each set.
• Setup Audit Trail — history of permission changes.

For orgs with complex permissions, periodic audits are healthy — find users with more access than they should have, permission sets unused for months, redundant assignments.

Migration From Profile-Heavy Orgs

If you inherited an org with 40 profiles and minimal permission sets:

1. Inventory. Diff every profile against a baseline. What’s actually different?
2. Extract. Convert per-profile differences into permission sets.
3. Compose. Group related permission sets into PSGs.
4. Assign. Users get PSGs; profiles revert to a minimal baseline.
5. Test. Every user must have access equivalent to their old profile.
6. Retire. Delete unused profiles once migration is verified.

Migration is weeks of work for a mature org. Budget accordingly.

Common Mistakes

Permission Set Groups that duplicate profiles. A PSG that grants everything a heavy profile granted isn’t an improvement. Decompose.

Over-granular permission sets. 50 permission sets each granting one tiny thing becomes unmanageable. Group related permissions.

Muting for things that belong in another PSG. If many users need the mute, make it a separate PSG instead of muting in place.

Forgetting to update PSGs. When a new permission is added for a role, update the PSG, not individual users.

Interaction With Sharing

Permission Set Groups grant object CRUD, field-level security, system permissions, and app access. They don’t grant record-level sharing. Sharing rules are separate.

A user in PSG_Sales_Rep has Account Edit permission but still needs sharing (via OWD, role, or rules) to see any specific Account. Permissions and sharing are orthogonal.

Frequently Asked Questions

How many PSGs can a user have?

Effectively unbounded by license, but practical limits on how many combinations are sane. Keep individual user assignments under 5–10 PSGs for manageability.

Do PSGs support expiration?

Permission set assignments (via group or direct) can have expiration dates. Useful for temporary access grants during projects or audits.

Can I package PSGs?

Yes — PSGs are metadata. Deploy via change sets, packages, or SFDX.

Are there performance concerns with many PSGs?

Minor. Permission evaluation is cached per user session. Real-world orgs with hundreds of PSGs perform well.