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 in 2027?

The outcome you should expect

The measurable outcome of this architecture is that personnel changes stop being engineering events. Before the change, a promotion in a profile-heavy org is a half-day of archaeology: find a "similar" AE, diff their access by eye, change the profile, discover three weeks later that CPQ never got turned on. After the change, a promotion is two clicks in the PermissionSetAssignment UI — or one attribute flip in your identity provider — and the entire capability delta between SDR and AE moves with it.

Set your target state against four concrete numbers. New-hire provisioning under two minutes: create the user, assign the base profile, assign one persona group, assign a role. There is no decision tree, because "this person is an AE" maps to exactly one permission set group. Promotion as a single reversible transaction: remove one group, add one group, with a timestamped assignment record for each. Profile count at or below two: one for the sales motion, one for everyone else internal, and a hard rule that neither is ever edited again after initial setup. Audit questions answered in two hops: "who can export reports?" resolves to "everyone assigned a group containing PS_System_ExportReports," which is a report you build once.

The governance property that matters most is that the promotion leaves the record-access layer untouched. Because the base profile carries the license, the default record types, the page layout assignments, and the login IP restrictions, and because record visibility comes from org-wide defaults plus the role hierarchy, swapping permission set groups changes only what the user *can do* — never what security baseline they operate under and never what records they see. In the old model, changing a profile changed all of those simultaneously, which is precisely why promotions broke things in ways nobody could reproduce.

A secondary outcome worth naming for a 30-rep RevOps team: the architecture becomes delegatable. Once "new AE" is a fixed recipe rather than tribal knowledge, a junior admin or a sales ops coordinator can execute it from a five-line runbook without escalating. That is the difference between an admin who is a bottleneck and an admin who owns the model. You cannot delegate a guessing game; you can absolutely delegate "base profile plus one group plus one role."

Expect the whole build for a 30-rep org to be roughly two permission set groups' worth of design work per week over three or four weeks, mostly testing, with no user-facing disruption if you migrate persona by persona. That is the realistic cost. The payoff arrives at roughly the third new hire.

What drives that outcome

Three mechanical properties of the Salesforce permission model produce every benefit above, and understanding them is what separates an architecture from a pile of sets.

Property one: permission sets compose, profiles do not. A user has exactly one profile but any number of permission sets, and the effective permission is the union across all of them. This means every time a real-world need is a *combination* — "an enterprise AE who also runs deal desk" — the profile model forces you to clone a third profile that hard-codes the combination, while the set model just assigns two groups. Profile counts grow combinatorially with persona overlap; permission set counts grow linearly. That single asymmetry is why fifteen-profile orgs exist and why nobody has fifteen persona groups.

Property two: permission set groups are compositions, not containers of raw permissions. A group holds *permission sets*, and a permission set can belong to many groups. So PS_Object_AccountRead lives simultaneously in the AE group, the SDR group, the Manager group, and the Ops group. Change it once, and all four personas update in the same instant. This is the propagation property the profile model could never deliver — in profile-world, granting a new field to "all AEs" means editing every profile that happens to represent an AE, by hand, hoping you did not miss one.

Property three: muting is the only subtraction mechanism. Permissions normally only accumulate upward; nothing is ever removed by adding a set. A muting permission set, which exists only inside a group, is the deliberate exception — any permission switched on in the muting set is subtracted from the group's net output even if a member set granted it. This is what lets you express a sub-persona as a subtraction from a parent rather than a fork. A "Junior AE" group contains the *identical* granular sets as the full AE group plus PS_Mute_JuniorAE, which mutes delete-Opportunity and export-reports. Both groups inherit every future improvement to the shared sets, because there is no fork to drift.

The fourth driver is not a platform property but a discipline: capability and record access live in separate compartments. Permission sets answer "what is this user in principle able to do to this object type." Org-wide defaults, the role hierarchy, and sharing rules answer "which specific records." A user needs both, and neither substitutes for the other. Teams that conflate them spend years adding permission sets to fix visibility problems, which never works, because the problem was never capability. Keeping the two compartments separate is what makes the whole system reason-about-able, and it is why the promotion swap is safe — it touches exactly one compartment.

The fifth driver is naming. A convention that makes the Setup list self-documenting — PSG_Persona_* for groups, PS_Object_* for object and field access, PS_Tool_* for connected apps, PS_App_* for packages, PS_Feature_* for gated features, PS_System_* for system permissions, PS_Mute_* for muting sets — means an admin who has never seen the org can sort alphabetically and read the architecture off the screen. The names *are* the documentation, and documentation that lives in the object names cannot go stale the way a wiki page does.

Benchmarks and realistic ranges

Here are the inventory numbers to aim for at 30 reps, and the ranges that indicate health versus rot.

Profiles: one to two, never more than four. "Standard Sales User" covers every quota-carrying or sales-adjacent person — AEs, SDRs, managers, sales ops, deal desk. "Standard Internal User" covers marketing, finance, CS, and executives outside the sales org. Keep two only if the populations genuinely need different license types, different default record types, or different login security baselines. If they do not, collapse to one. Anything above four profiles at this headcount means capability has leaked back into the profile layer.

Persona permission set groups: five, plus one or two sub-persona variants. PSG_Persona_AE, PSG_Persona_SDR, PSG_Persona_SalesManager, PSG_Persona_SalesOps, PSG_Persona_DealDesk. Add PSG_Persona_AE_Junior via muting if you ramp new AEs. Deal desk is typically one to three people at this size; sales ops one to two; managers three to five, each over a pod of five to eight reps; the remaining twenty-four to twenty-eight are individual contributor AEs and SDRs.

Granular building-block sets: fifteen to thirty. Object-and-field sets are the workhorses — PS_Object_OpportunityEdit, PS_Object_OpportunityCreate (create-only, for SDRs generating pipeline they do not own), PS_Object_OpportunityViewAll, PS_Object_AccountEdit, PS_Object_AccountRead, PS_Object_LeadEdit, PS_Object_LeadConvert, PS_Object_ContactEdit, PS_Object_QuoteEdit, PS_Object_ContractEdit. Then feature sets (PS_Feature_Forecasting, PS_Feature_ForecastingManage, PS_Feature_ApprovalProcessAdmin), app sets (PS_App_CPQ, PS_App_DataLoader), tool sets one per connected app, and system sets (PS_System_ReportCreate, PS_System_ReportRun, PS_System_ExportReports, PS_System_BulkApiAccess, PS_System_ApiEnabled). If you are under ten granular sets, you have probably built giant bundles that cannot be composed or muted precisely. If you are over forty at 30 reps, you have probably made sets that are one-off exceptions rather than reusable bricks.

Role hierarchy: three to four levels, full stop. CRO or VP Sales at level one; one or two sales directors at level two, split by segment or geography; three to five front-line managers at level three; the reps as leaves at level four. Sales ops and deal desk sit off to the side — their own small branch under the CRO, or a peer role granted broad access via sharing rules, because they need to see everything and hierarchy rollup alone would only give that to the CRO. Depth beyond four levels buys nothing but confusion at this headcount.

Org-wide defaults: Private on Opportunity, Account, and usually Lead. Private means you see only what you own by default, and you open access upward deliberately through the hierarchy and sideways through sharing rules. Setting OWD Public and clawing access back later is materially harder and is the more common source of a governance finding.

Direct standalone permission set assignments: as close to zero as possible. In a healthy layered org, almost everyone's access arrives through their persona group and nothing else. Every direct assignment on a user record is either a documented, owned, expiring exception or it is a cleanup target. This is the single best health metric you have — track the count quarterly and drive it down.

The size sweet spot argument. Thirty reps is exactly where this fix is cheap. At five reps you can get away with anything. At three hundred, remediating a bad model is a multi-quarter project with real change-management overhead. At thirty you have enough distinct personas and enough hiring velocity — typically one to three people a month at a growing B2B company — that the cracks are visible, but the cleanup is still weeks of part-time work. Teams that adopt the layered model before they have fifteen profiles pay a fraction of what teams that adopt it after do.

Risks, edge cases, and failure modes

Failure mode: the permission set license layer silently blocks you. You build PS_App_CPQ, drop it in the AE group, and nothing happens. The cause is almost never a permission bug — it is the license layer. Salesforce gates some capabilities behind *permission set licenses* consumed when the relevant set is assigned, and behind the user's underlying *user license*. A Platform-license user cannot touch Opportunity no matter how many sets you stack. Before debugging a set, verify: does the org own enough of that permission set license, is the user's user license compatible, and is any legacy feature license (Marketing User, Knowledge User) required. Map each persona group to the licenses it consumes per assignee, and track consumption quarterly so you do not learn you are out of CPQ seats on a deal-desk hire's first morning.

Failure mode: the half-finished promotion. The user ends up with a hybrid — the AE group added but the SDR group left on, or the profile changed while the groups were not swapped, or a one-off patch applied to paper over the gap. The result is a rep with strange residual capability that nobody can explain later. The rule that prevents it: the promotion is *always exactly* remove PSG_Persona_SDR, add PSG_Persona_AE, and nothing else. No profile change, no patches, no "while I'm in here." If that one operation does not fully provision the user, the bug is in the AE group's definition, and you fix the definition, which fixes every future promotion at once. Resist fixing the individual — it hides a defect that will resurface on the next promotion.

Failure mode: reaching for a permission set to fix a visibility problem. A manager cannot see a rep's deal. The instinct is to add permissions. It will not work, ever, because this is a record-access problem: the rep is not below that manager in the role hierarchy, or org-wide defaults plus the hierarchy are not rolling up as expected. Fix the hierarchy or write a sharing rule. Every hour spent adding capability to solve a sharing problem is an hour of drift injected into your architecture, and the leftover grants are exactly what a hygiene review flags a year later as unexplainable access.

Failure mode: muting used as a general-purpose exception mechanism. Muting is for genuine sub-personas with a stable, documented subtraction — a Junior AE who should not delete Opportunities or export reports. It is not for one-off employee exceptions. If you find yourself creating a muting set per person, you have recreated the profile-per-role problem with a new name. Cap yourself at one or two muting sets in a 30-rep org and require that each one name a persona, not a person.

Failure mode: the integration user borrowing a human persona. Never run an integration through a real person's login, and never assign a human persona group to a service account. Each integration gets its own user — "Integration - Snowflake," "Integration - Marketo" — plus its own purpose-built set, PS_Integration_<System>, granting exactly the object access, field-level security, and API permission that one integration calls. Human persona groups grant far more than any integration should have. Add API and Bulk API where needed, restrict UI login and report creation, and pin login IP ranges where the source is stable. Re-justify each integration set quarterly against what the integration actually calls, because integration scope creeps by one object at a time and is never revisited.

Edge case: field-level security on sensitive fields. Commission rate, margin, cost, internal scoring — these should be hidden or read-only for reps and editable only by ops or finance. Encode that as a dedicated PS_Object_OpportunitySensitiveFields set assigned only to ops personas, rather than trying to express it as an exception inside the shared AE set. And remember that field-level security is capability, not visibility: an AE with edit on a field still only sees it on records the sharing model surfaces.

Edge case: territory management. At 30 reps the role hierarchy plus a handful of sharing rules is sufficient, and Enterprise Territory Management is over-engineering. It earns its keep when account-to-rep assignment is genuinely rules-driven — geography, named-account lists, segment — and churns often enough that manual sharing cannot keep up. That is usually a hundred-plus-rep reality. Adopting it early adds a whole sharing computation layer you then have to reason about during every promotion.

Edge case: the genuinely tiny org with no admin. If you have no one to maintain the model, two profiles may legitimately be enough and the layered build is premature. But that argument expires fast: with 30 reps and any growth trajectory, the layered model pays for itself within about three new hires, and the cost of the migration rises with every profile you clone in the meantime.

The compliance risk of getting it wrong. If you hold or are pursuing SOC 2 or ISO 27001, the access-control criteria want evidence that users have the minimum access their role requires, plus a recurring documented access review, plus clean provisioning and de-provisioning trails. A drifted fifteen-profile org answers those questions with manual cross-referencing and usually a finding. The layered model produces the evidence as a byproduct: every user has their persona group, each group is a documented composition, and the promotion is a single timestamped assignment change record — SDR group removed, AE group added, attributable. Governance and operational ease are the same property viewed twice, not a trade-off.

A practical rollout plan

Most teams are not greenfield — they have the fifteen-profile mess today. The migration is low-risk if you go persona by persona and never big-bang.

Step one, inventory (roughly one week, part time). Document every existing profile: who is assigned, what it grants across object permissions, field-level security, system permissions and app access, and which real-world persona it actually represents. Expect fifteen profiles to collapse into about five genuine personas with substantial drift between supposedly identical profiles. That collapse *is* your target group list, and the drift you find is the evidence that justifies the project.

Step two, design on paper before touching the org. Write the architecture page: the base profiles and exactly what they grant, the five persona groups and their granular-set composition, the granular-set inventory with a one-line description each, the role hierarchy diagram, and the onboarding runbook. For a 30-rep org this genuinely fits on one page. Use the Description field on every set and group as you build — one sentence saying what it grants, why it exists, which groups consume it, and who owns changes to it.

Step three, build in a sandbox. Construct the granular sets, assemble them into groups, and test by assigning a new group to a test user *alongside* their existing profile. The union should give them everything they had. Use "Log in as" to walk each persona's actual daily workflow, and use the permission set group calculation and assignment preview to inspect the net effective permission before it reaches a real user — that catches muting sets that mute more than intended and two sets that combine to grant something unexpected.

Step four, migrate the lowest-risk persona first. SDRs are usually the right starting point: fewest integrations, simplest object needs, lowest blast radius. Move them onto the thin base profile, assign PSG_Persona_SDR, and verify each user retains exactly their prior capability. Then the next persona, then the next. Never migrate all five in one window.

Step five, collapse the old profiles. As each persona migrates, the legacy role-specific profiles empty out. Once a profile has zero users, rename it ZZ_DEPRECATED_<name> so it sorts to the bottom and nobody assigns it by accident, observe for a cycle, then delete it.

Step six, validate with a diff. Build the access-review report — users by group, users with direct non-group assignments, sets by assignee count, and who holds each system permission. Snapshot it before each persona migration and diff after. The diff should show exactly the intended change and nothing else; an unexpected line is a bug you caught for free. That same report is your recurring access-review artifact for compliance, so you build it once and use it in both places.

Step seven, automate the deterministic recipe. Manual assignment is genuinely fine at 30 reps — it is a two-minute task — but automation removes the last source of human inconsistency. The simplest version is a record-triggered flow on the User object that reads a custom Persona picklist and creates the matching PermissionSetAssignment. Onboarding becomes "create user, pick persona, save," and the flow cannot forget the CPQ set the way a hurried admin can. The scale version drives creation and assignment from your identity provider via SCIM: HR moves the person from the SDR group to the AE group in the IdP, the assignment swaps automatically end to end, and the IdP becomes the auditable system of record for who is what. Also use time-bound assignments with an end date for contractors, interns, and temporary deal-desk coverage — self-expiring access is both a least-privilege win and clean evidence. None of this is possible in the profile-per-role world, because you cannot automate a guessing game; you can only automate a deterministic recipe, and the layered model is what makes the recipe deterministic.

Step eight, run the quarterly hygiene review. Budget two hours. Find orphaned sets assigned to zero users and belonging to zero groups, and either document why they exist or delete them. Find over-provisioned users whose assignments do not match their persona. Drive down direct standalone assignments. Pay down permission set debt — re-split any set that drifted from single-purpose into bundling three unrelated things, and fold recurring exceptions into a persona group or formally document them with an owner and expiry. Cross-check license consumption. Then re-run the access-review report. This is the discipline that keeps the model from becoming the next fifteen-profile mess wearing a different costume, and for a RevOps team it doubles as the documented access review your auditors will ask for anyway.

Related questions

Should the role hierarchy change when an SDR is promoted to AE?

Usually yes, but only if they move to a different manager's pod. The hierarchy exists solely for record rollup, so it changes when reporting lines change — not because the job title changed. A Senior AE and a Junior AE are the same hierarchy role.

Can one user have two persona permission set groups?

Yes — assignments are additive, so an AE who also staffs deal desk can hold both groups. Prefer that over building a combined group. Reserve genuinely combined groups for durable hybrid roles that more than one person holds, and document why.

What happens to a permission set group when a member set changes?

Salesforce recalculates the group's aggregate permissions, and every user assigned the group gets the change. That propagation is the point: fix a missing field once in PS_Object_OpportunityEdit and every AE, current and future, is fixed.

Do we still need profiles at all?

Yes, but only as a thin shell. Profiles still carry license assignment, default record types, page layout assignments, login hours, and login IP ranges. Salesforce's stated direction moves granted permissions out of profiles entirely, so build as if that has already happened.

How do we handle a promotion that is later reversed?

Swap back: remove the AE group, re-add the SDR group. Because the base profile and role were untouched, nothing else needs restoring, and both assignment changes are timestamped records that make the whole sequence legible to an auditor.

FAQ

Why not just clone the AE profile and call it done?

Because profiles are exclusive — a user has exactly one — so every combination of needs forces another clone, and profile counts grow combinatorially rather than linearly. Cloned profiles also drift immediately: within a year no two "AE" profiles are actually identical, changes have to be applied by hand to each one, and no single artifact defines what an AE gets. The clone is fast today and expensive forever.

What is the actual difference between a permission set and a permission set group?

A permission set is a single additive bundle of permissions — object access, field-level security, system permissions, app and Apex access — assigned directly to users. A permission set group contains *permission sets*, not raw permissions, and is assigned as one unit. Use standalone sets for reusable building blocks and genuine one-offs; use groups to define personas. The group is your composition layer.

Does adding a permission set ever take access away?

No, with exactly one exception. Effective permission is the union of the profile and every assigned set, so grants only accumulate upward. The exception is a muting permission set, which exists only inside a group and subtracts a permission from that group's net result even if a member set granted it. Muting does not alter the member set itself — other groups using that set are unaffected.

Our sales manager cannot see a rep's opportunity. Which permission set fixes it?

None of them. That is a record-access problem, not a capability problem. Check whether the rep sits below that manager in the role hierarchy, what the org-wide default is on Opportunity, and whether a sharing rule is needed for the sideways cases — peers in a pod, deal desk seeing all opportunities, marketing seeing all leads. Adding capability here creates drift without fixing the symptom.

We assigned the CPQ permission set and nothing happened. Why?

Check the license layer first — that is the cause roughly nine times out of ten. Some capabilities require a permission set license consumed on assignment, and the org can run out of them; separately, the user's underlying user license may be incompatible with the capability entirely. Verify seat counts and license compatibility before touching the set's contents.

How much ongoing maintenance does this architecture actually take?

For a 30-rep org, about two hours a quarter. The review covers orphaned sets and groups, over-provisioned users, direct standalone assignments that bypass the persona model, permission set debt from bloated or drifted sets, and license consumption. Everything else — onboarding, promotions, tool rollouts — is routine work measured in minutes because the model made each of those a fixed recipe.

Sources

• https://help.salesforce.com/s/articleView?id=sf.perm_sets_overview.htm
• https://help.salesforce.com/s/articleView?id=sf.perm_set_groups.htm
• https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_muting.htm
• https://help.salesforce.com/s/articleView?id=sf.security_sharing_owd.htm
• https://help.salesforce.com/s/articleView?id=sf.admin_roles.htm
• https://help.salesforce.com/s/articleView?id=sf.users_profiles_about.htm
• https://trailhead.salesforce.com/content/learn/modules/data-security
• https://architect.salesforce.com/well-architected/trusted/secure
• https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_permissionsetassignment.htm
• https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2

Related on PULSE

• How should a 30-rep sales org structure its Salesforce role hierarchy for accurate forecast rollup?
• What org-wide defaults and sharing rules does a private-by-default Opportunity model actually need?
• How do you build a RevOps onboarding runbook that provisions a new AE in under five minutes?
• What belongs in a quarterly Salesforce access review for SOC 2 evidence?
• How should integration and API service accounts be scoped in a growing Salesforce org?
• When is Enterprise Territory Management worth the complexity versus role hierarchy plus sharing rules?