Blog/Permission sets at scale (without turning your org into a junk drawer)

Permission sets at scale (without turning your org into a junk drawer)

A permission model using groups, naming, and isolation of dangerous privileges—without turning access into chaos.

Casey Ward9/6/20251 min readSecurityAccessAdmin

At ~10 permission sets, everyone’s optimistic. At ~60, nobody remembers what anything does. At ~120, someone proposes “let’s just clone the profile.”

You can avoid that slide into chaos with a few rules: bundle by job, isolate the sharp permissions, and name things like a grown-up.

Here’s a model that holds up when your org keeps growing.

A model that works in messy orgs

  • Profiles: baseline login + app access
  • Permission Set Groups: job roles
  • Small “sharp edge” permission sets: export, view all, overrides

Build role bundles (PSGs)

Examples:

  • Support Agent
  • Support Lead
  • RevOps Analyst
  • Billing Ops

If your PSG description is literally “perm set group,” you are not done.

Naming that doesn’t collapse at 200 entries

Prefix by type:

  • APP - ...
  • OBJ - ...
  • FLD - ...
  • SYS - ...
  • INT - ...

Now the list sorts itself and your eyes stop bleeding.

Stop using “View All” as duct tape

If someone needs more records, fix sharing.
“View All” should be rare and justified, not the default because “it’s easier.”

Two patterns worth copying

  1. Sensitive fields set: tax IDs, banking, discount overrides—one place
  2. Integration bundle: integration users get least privilege, not “copy what Sales has”

Checklist

  • profiles minimal and stable
  • PSGs match roles
  • export/view all isolated
  • integration access isolated
  • naming consistent

Want help implementing this?

If you have a backlog and want steady delivery without surprise projects, we can handle admin-sized work under a monthly subscription.