What is the right Salesforce permission set architecture for a 30-rep team that does not break governance when an SDR gets promoted to AE?
Quick take: Build permission set GROUPS by function (one per persona: SDR, AE, AM, Manager, RevOps, Deal Desk, Marketing), not by individual user. When an SDR gets promoted, you swap one group assignment for another — no rebuilding required, no 90-minute access audit, no broken reports.
The Detail
The pattern that breaks at 30 reps is the one you inherit from a Series A founder who used Salesforce's default profiles plus a sprinkle of permission sets. The profile is "Standard User" or "Sales User," and access creeps in via 14 individual permission sets layered on top. Promote that SDR to AE and now you have to: revoke 6 permission sets, add 4 new ones, change the role hierarchy, update the queue membership, and pray nobody references their old user lookup. You won't get it right. Field-level audit will fail.
The fix is permission set groups (PSGs), GA since Spring '20. PSGs let you bundle 3-12 individual permission sets into a single assignable unit and use muting permission sets to subtract from a group without rebuilding it.
The Right Architecture
Use a "minimum profile + functional PSGs" pattern. Salesforce's own Architect Decision Guide endorses this.
Step 1: Standardize profiles. Use ONE profile for nearly all sales users — "Sales Standard Profile." Strip it to bare essentials: object access at view-only, no field-level permissions, no record types. The profile becomes a license-binding skeleton, not a permission carrier.
Step 2: Build functional PSGs. One PSG per persona:
PSG_SDR— read/write on Lead, Contact, Account (limited fields); read-only on Opportunity; access to Outreach or Salesloft connector; Cadence object access.PSG_AE— full CRUD on Opportunity, Contact, Account; CPQ Quote read/write; read-only on Lead (so they don't poach); forecast category edit rights.PSG_AM— full CRUD on Account, Contract, Asset; renewal-stage Opportunity edit; QBR template access.PSG_Manager— adds approval-process edit, forecast-rollup view, and the manager dashboard folder.PSG_RevOps— system admin without modify-all-data; report folder owner; custom metadata edit.PSG_DealDesk— discount-approval queue membership; quote-approval routing; CPQ rule override.PSG_Marketing— Campaign full CRUD; Lead read; Pardot or Marketo sync object access.
Step 3: Use muting permission sets for exceptions. A junior AE who shouldn't have full discount authority gets PSG_AE + a muting PSG that removes the "Approve Discount" permission. No need to fork the group.
Step 4: Automate assignment with a flow. When the User record's "Role" field changes, a record-triggered flow removes the old PSG and assigns the new one. This is the SDR→AE promotion in one click: change the role, flow does the rest, the audit log captures it.
The SDR → AE Promotion Sequence
What NOT to Do
Don't assign permission sets one at a time. Don't use the "View All Data" or "Modify All Data" permissions outside of RevOps/Admin (it bypasses sharing rules and breaks every territory model). Don't create "AE_West" and "AE_East" as separate PSGs — geography belongs in the role hierarchy and territory model, not in permissions. Don't let the Profile do real work; it's there for license-binding and a few system permissions (login hours, password policy).
Comparison: Old Profile-Heavy vs Modern PSG Pattern
| Dimension | Old Profile-Heavy | Permission Set Groups |
|---|---|---|
| Promotion time | 45-90 minutes manual | < 30 seconds via flow |
| Audit clarity | Profile + 14 perm sets to inspect | One group, named by persona |
| Mistake recovery | Rebuild from backup | Remove group, reassign |
| Compliance for SOX/SOC 2 | Spotty; needs change log scripting | Built-in audit trail on group assignment |
| Scales to 100+ reps | Falls over | Designed for it |
| License optimization | Hard — profiles bind license type | Easy — PSGs are license-agnostic |
Implementation Tips
Build this in a sandbox first. Use Salesforce DX or Gearset to source-control the PSGs so you can promote them through dev → staging → prod. Document each PSG in a Confluence or Notion page with: purpose, permissions included, who assigns it, who approves changes. Run a quarterly access review where the CRO or RevOps Lead signs off on the persona-to-PSG mapping. SalesforceBen has a solid practitioner walkthrough on PSGs that's worth handing to your admin.
Sources
- Salesforce Help — Permission Sets Overview: https://help.salesforce.com/s/articleView?id=sf.perm_sets_overview.htm
- Salesforce Architect — Permissions Decision Guide: https://architect.salesforce.com/decision-guides/permissions
- SalesforceBen — Permission Set Groups: https://www.salesforceben.com/permission-set-groups/
- Trailhead — Identity and Access: https://trailhead.salesforce.com/content/learn/modules/identity_login
- Gartner Sales Research: https://www.gartner.com/en/sales/research
- OpenView SaaS Benchmarks: https://openviewpartners.com/blog/saas-benchmarks/
The 30-rep test is whether a promotion takes one click or one afternoon — if it takes the afternoon, your architecture is already failing.
TAGS: salesforce-permissions, permission-sets, governance, role-transitions, salesforce-architecture