⚙️ AdminBeginner2026-03-04

Permission Set Groups: The Modern Approach to Salesforce Security

Profiles are legacy. Salesforce has said it publicly: profiles are going away and permission sets are the future. But managing 20 permission sets per user is a nightmare, which is why Permission Set Groups exist. A Permission Set Group bundles multiple permission sets into a single assignable unit. Assign the group to a user and they get all the permissions from every set in the group.

The strategy is to build atomic permission sets — one per feature or object. "Case_Read", "Case_Edit", "Knowledge_Author", "Reports_Builder". Then combine them into groups that represent job functions: "Support_Agent" (Case_Read + Case_Edit + Knowledge_Author), "Support_Manager" (Support_Agent + Reports_Builder + Dashboard_Edit). This is composable, auditable, and scales with your org.

The secret weapon is muting permission sets within groups. If the "Support_Agent" group includes "Case_Edit" but you need one specific user to have read-only access, add a muting permission set to their group assignment that removes edit access. This eliminates the need for cloning profiles or creating one-off permission sets. Use muting sparingly — it adds complexity — but it solves the "almost but not quite" permission problem cleanly.

Code Example

// Permission Set Architecture:

// Layer 1: Atomic Permission Sets (granular)
// ├── Case_Read         → Read on Case object
// ├── Case_Edit         → Create/Edit on Case
// ├── Case_Delete       → Delete on Case
// ├── Knowledge_Author  → Create/Edit on Knowledge
// ├── Reports_Builder   → Build reports
// └── Dashboard_Edit    → Edit dashboards

// Layer 2: Permission Set Groups (job functions)
// Support_Agent (group):
//   ├── Case_Read
//   ├── Case_Edit
//   └── Knowledge_Author
//
// Support_Manager (group):
//   ├── Case_Read
//   ├── Case_Edit
//   ├── Case_Delete
//   ├── Knowledge_Author
//   ├── Reports_Builder
//   └── Dashboard_Edit

// Layer 3: Muting (exceptions)
// Support_Agent_No_Edit (muting perm set):
//   └── Removes: Create/Edit on Case
// Assign to specific user within Support_Agent group

// Setup Steps:
// 1. Setup → Permission Sets → New (create atomic sets)
// 2. Setup → Permission Set Groups → New
// 3. Add permission sets to the group
// 4. (Optional) Create muting permission set
//    Setup → Permission Set Groups → [Group] → Muting
// 5. Assign group to users (instead of individual sets)

// Audit: Setup → Permission Set Groups → [Group]
// Shows all included sets, muting sets, and assigned users
// Far cleaner than checking 20 individual perm set assignments

Share this tip on X

Need this implemented in your org?

I've shipped these patterns in production for 10+ years.

View Consulting →

CI/CD for Salesforce: GitHub Actions Pipeline That Validates Every PR

Enjoyed this? Get more like it.

Glen's Musings — AI, investing, and building things. Occasional. Free.