Sizing a Salesforce Access Model: Team Shape, Internal vs External Admins, and What It Costs to Run

Part 3 of 4 in the Salesforce Delivery Team Access series. Part 2 describes the full model. This part is about how much of it you should actually build.

TL;DR

• The model in part 2 is sized for a delivery team of ten to twenty-five across several orgs. Most teams are not that shape, and building the full thing at the wrong scale is how access design gets abandoned.
• It scales with the number of orgs and delivery partners more than with headcount. Eight people in one org need very little. Eight people across six orgs with two partners need most of it.
• Every component has a capability prerequisite. Building one you cannot maintain is worse than not building it, because it fails silently and leaves you believing you are covered.
• External delivery partners need a different shape, not simply less access: expiring assignments, internal-only approvers, per-partner attribution, and counterintuitively broader access in the low tiers.
• Full model: roughly 15 to 25 build days and about 15 hours a month. Production-only: roughly 8 to 10 days and 3 to 5 hours a month for about 85 percent of the risk reduction.
• Access models are rarely rejected. They are adopted and then abandoned, because nobody costed the running overhead.
• Treat the admin team as a platform team and access as a service. An approval queue is the wrong interaction mode for a permanent, high-frequency need, so aim at self-service elevation with an expiry and a public log rather than at faster approvals.

What You'll Learn

• Which parts of the model to build at four different team scales, and which to skip
• The capability prerequisite behind each component, and the fallback when you lack it
• How the model flexes for internal teams, external delivery partners, and the hybrid arrangement most organisations actually run
• Why an approval queue is the wrong shape for step-up access, and what to build instead
• What the whole thing costs to build and to run each month, with failure modes per component
• An adoption order that front-loads the risk reduction and defers the expensive parts

The Problem

Every access model looks good in a document. The reason most of them are abandoned eighteen months later is not that they were wrong, it is that nobody costed the running overhead, and nobody asked whether the team had the capability to maintain what was being proposed.

There is a second failure that is subtler. A team builds a component it cannot maintain, that component quietly stops working, and the organisation carries on believing it is protected. An access control that has silently failed is worse than one you consciously chose not to build, because it removes the awareness that would otherwise drive compensating behaviour.

So before building anything from part 2, two questions are worth more than the design itself: how much of this does a team our shape actually need, and which components can we genuinely keep alive?

Common Questions This Article Answers:

• We're a small admin team. Does any of this apply to us?
• How should the model change if our admins are an external partner rather than employees?
• What does a least-privilege access model actually cost to run each month?

Quick Answer

Size the model to your team. A one-to-three-person admin shop needs separate named admin accounts, daily-driver users on Minimum Access, and MFA on both. That is roughly a day of work and it captures most of the available benefit. A four-to-ten-person delivery team should restrict production only and use one flat permission set per role. Ten to twenty-five with a DevOps function can justify per-tier role groups and drift monitoring. Only at programme scale, or with multiple delivery partners, does the full capability matrix earn its keep.

Then check capability before building. Post-copy automation needs someone who maintains production Apex. Session-based step-up needs someone who owns a flow as production software. Drift monitoring needs a named person who reads the report. Where you lack the prerequisite, take the documented fallback rather than building something that will decay.

For external delivery partners, change the shape rather than reducing access uniformly: make assignments expire by default, require internal approvers, name role groups per partner for attribution, and deliberately give partners broader standing access in low tiers so your internal admins do not become an approval bottleneck.

Match the model to your team's shape

Team shape	Build this	Skip this
One to three admins, no developers, no pipeline	Separate named admin accounts used only for admin work, daily-driver users on Minimum Access, MFA on both	All of it. Permission set groups per tier solve a problem you do not have.
Small delivery team, four to ten, some Apex, a working pipeline	Production-only restriction, one flat permission set per role, a scoped CI user	Capability decomposition, tier-specific role groups, post-copy automation
Delivery team of ten to twenty-five with a DevOps function	The production and staging model, per-tier role groups, drift monitoring	The full capability matrix and automated provisioning, until something forces them
Programme scale, twenty-five plus, or multiple delivery partners	The full model, including capability sets, automated provisioning, and per-partner role groups	Nothing. At this scale the alternative is worse.

The pattern is that the model scales with the number of orgs and delivery partners more than the number of people. A team of eight working in one org needs very little of this. A team of eight working across six orgs with two delivery partners needs most of it, because attribution and consistency are the problems rather than headcount.

Build only what you can maintain

The useful way to read the table below is as a cognitive load budget. Team Topologies splits load into intrinsic (the domain itself), extraneous (the toolchain and process around it), and germane (the thinking that actually creates value). Every component here is extraneous load: none of it ships a feature. It is worth carrying only where it removes more risk than the attention it consumes, and a team can only carry so much before something silently stops being maintained.

Component	Requires	If you lack it
SandboxPostCopy automation	Someone who writes and maintains production Apex with real test coverage	Do not restrict sandbox access at all. Restrict production only, and treat that as the permanent design rather than phase one of something bigger.
Session-based step-up via an approval flow	Someone who owns that flow as production software, including its monitoring	Use manual assignment plus a scheduled job that revokes anything older than a day. Cruder, and its failure mode is far kinder.
Assignment drift monitoring	A named person who reads the report every week	Do not build it. An alert nobody reads is false assurance, which is worse than no alert at all.
Removing production Customize Application from functional consultants	A pipeline with a median deploy time under roughly fifteen minutes	Leave them with production configuration access and record it as a knowing, documented acceptance rather than an oversight.
Per-tier role permission set groups	More than one sandbox tier whose access genuinely differs	One permission set per role, applied everywhere, with production handled separately.
Capability set decomposition	Three or more roles that genuinely share a capability	Flat role permission sets. Decomposing early multiplies objects without reducing anything.

That last row is worth dwelling on, because the instinct to decompose is a good engineering instinct applied in the wrong place. Ten small capability sets composed into role groups is more metadata to deploy, review, and recertify than a handful of flat role sets that are just as auditable. Decompose when duplication actually hurts, not in anticipation.

The step-up row deserves a note too, because it is a case where the better design has the worse failure mode. Session-based permission set groups expire on their own, which is genuinely superior. But they depend on an activation flow, and if that flow breaks, nobody can obtain elevated access and the team falls back to break-glass. A scheduled revocation job is cruder, and when it fails, access simply lingers until the drift report catches it. Choose mechanisms by how they fail, not by how they look on a diagram.

Internal, external, and hybrid admin teams

Who runs your org changes this model more than anything else discussed so far, because an internal team is governed partly by controls that have nothing to do with permissions. Employment contracts, vetting, a disciplinary process, and an HR system that deactivates accounts on someone's last day are all real controls. You have none of them over a delivery partner.

Dimension	Internal team	External team	Why it differs
Offboarding trigger	HR system, same day, identity provider integrated	You find out at standup that someone rolled off	The single biggest difference. Partner staff rotate without telling you.
Assignment default	Granted until removed	Expiring by default, renewed on request	Compensates directly for offboarding blindness.
Identity source	Your identity provider, your MFA, managed devices	Accounts in your identity provider, not federated from theirs	You must own the lifecycle. Device posture is unenforceable, so compensate with login IP ranges.
Step-up approver	Peer approval is acceptable	Must be internal, always	External approving external voids the control entirely.
Tier boundary hardens at	T3	T2	Unmasked real data reaching a third party is a different category of question.
Standing access in T0 and T1	Standard	Broader than internal	Counterintuitive but correct, see below.
Break-glass custody	Internal named holders	Never held externally	No exceptions worth making.
Role group naming	By role	By role and partner	Attribution, see below.
Automated provisioning	Defer it	Build it early	Roster churn is much higher, so it pays back faster.
Deployment pipeline	Yours	Still yours	Partners deploy through your pipeline, not their own tenant of a deployment tool.

Two of those rows deserve more than a table cell.

Broadening low-tier access for external teams is deliberate. The instinct is to give a partner less of everything. That produces a step-up request queue that lands entirely on your internal admins, and an approval queue is a coupling: a production issue now waits on a specific person being at their desk. Give external builders generous standing access in developer and integration sandboxes, where the data is synthetic and the blast radius is a broken sandbox, so that the genuinely sensitive tiers see very few requests. Restrict hard where it matters and stop restricting where it does not.

Per-partner role groups are commercially useful, not merely tidy. Separate groups per delivery partner make Setup Audit Trail attribution unambiguous. If you ever end up in a dispute with a partner about quality, scope, or who broke what, being able to demonstrate exactly who deployed which change and when is worth considerably more than the effort of maintaining a second set of permission set groups. Shared or ambiguous accounts destroy that evidence at precisely the moment you need it.

One further consideration if your delivery partner works from another country: access to real records from outside your jurisdiction can engage privacy and disclosure obligations rather than only security controls, which makes the tier boundary a compliance decision rather than an engineering one. That is a question for your privacy officer rather than your architect, and it is worth asking before rather than after. Salesforce data sovereignty in New Zealand covers the surrounding ground for NZ organisations.

The hybrid case is what most organisations actually have: an internal admin team plus an external build team. It resolves cleanly. Internal admins hold the assignment permissions, own break-glass, and approve every step-up, which makes them the only people with Manage Users and Assign Permission Sets above T2. External builders get generous low-tier access, expiring assignments, per-partner groups, and no route to production except the pipeline.

Be honest about what that does to the internal team's job, because it is the part that gets skipped. Their role shifts from building to approving and monitoring. If your internal admins are already fully committed to delivery work, adding an approval queue to their week will fail quietly. Staff it deliberately or accept that step-up will be slow, but do not pretend it is free.

The admin team is a platform team, not a queue

Team Topologies by Matthew Skelton and Manuel Pais gives the sharpest available critique of everything described so far, and it is worth applying because it changes a recommendation rather than merely renaming one. The larger question of how that book maps onto Salesforce org and team design has its own post, Team Topologies for Salesforce: the org is the fracture plane; here I am using only the part that bears on access.

The book separates two ways teams interact. Collaboration is high-bandwidth, expensive, and deliberately temporary: two teams work closely to discover something, then stop. X-as-a-Service is low-bandwidth and ongoing: one team consumes a capability another provides, through a clear interface and with minimal conversation.

A step-up approval queue is collaboration applied to a permanent need. Every production access request opens a synchronous conversation between a delivery engineer and an admin. That is the right mode for solving a novel problem and exactly the wrong one for a routine, high-frequency transaction. The symptom is the coupling described above: a production incident now waits on a specific person being at their desk.

Reframed, the internal admin team is a platform team, and access is the service it provides. The test of a platform team is whether consuming its service reduces the cognitive load of the teams using it. An approval queue increases it. The delivery engineer now has to know who to ask, whether they are available, and how long the wait will be, none of which is about the work.

So the target state is self-service elevation rather than faster approval. An engineer requests elevated access, states a reason and a ticket reference, receives it immediately, and every activation is logged and published to a channel the whole team can see. No human in the path. The control is not the approval, it is the expiry, the log, and the visibility. Approval gates feel safer and mostly buy latency.

Two caveats before you delete the approver. Self-service belongs at the tiers where the blast radius is survivable and activity is genuinely visible, so break-glass in production stays deliberately manual and awkward. And self-service is only honest if somebody actually reads the log, which is the same named-owner prerequisite as the drift report.

Cognitive load is also the better unit for the cost table below. Hours are easy to count and they understate the real price, because every step-up request is an interruption, and interruptions are paid for in context switches by exactly the people you most want in flow.

What this actually costs to run

Here is the bill, as estimates for a team of roughly a dozen across several orgs rather than measured data. Argue with the numbers, but do the exercise.

Component	Build (days)	Run (hrs/month)	Failure mode	Verdict
Baseline profile and role permission sets	3 to 5	~3	Deploy fails, caught in the pipeline	Build. This is the model.
Read-only production role and break-glass	1	~1	Benign	Build first. Best ratio here.
CI identity split, IP lock, JWT	2	~0, plus annual certificate rotation	Pipeline stops, loudly	Build. Almost no running cost.
Drift report on staging and production assignments	1	~2	Silent, because nobody reads it	Build only with a named owner.
Step-up via scheduled revocation	1	~5	Access lingers, drift report catches it	Build this version first.
Step-up via approval flow	2 to 3	~5	Nobody can work, so people use break-glass	Defer. Better design, worse failure mode.
Capability set decomposition	2	~3	Metadata sprawl, recertification collapses	Skip below programme scale.
SandboxPostCopy	3 to 5	~2, spiky	Blocks the entire team	Defer. Worst profile in the model.
Automated provisioning policies	1 to 2	~1	Wrong access assigned automatically	Defer for internal teams, build early for external ones.
Documentation and training	2	~3, decaying	Confusion, then workarounds	Build. Not optional.

Three observations from that table matter more than the totals.

SandboxPostCopy has the worst operational profile of anything here. It runs infrequently, so it is chronically under-tested. It has enormous blast radius, because a failure blocks everyone. And it fails silently until somebody tries to work. Code that runs rarely and stops everyone when it breaks is the least forgiving shape an operational dependency can take, which is why it belongs last rather than first.

Your org count is the multiplier, not your headcount. A dozen people generate modest permission churn, but every capability change is a deploy and a verification per org. With seven orgs, a single "the testers need X" request becomes seven deployments. This is the strongest argument for keeping the metadata count low.

Overhead and risk reduction are distributed completely differently. The production-only work is roughly sixty percent of the risk reduction for two to four hours a month. The full tier and capability matrix is the last fifteen percent of the risk for ten to twelve hours a month plus two permanent software dependencies. That is a poor trade at most scales.

To be fair to the model, three things do get cheaper. Offboarding stops requiring anyone to reason about what a System Administrator profile touched. Access review evidence becomes a query rather than an exercise, which offsets real work if you already carry ISO 27001, NZISM, or sector obligations. And incident attribution narrows from "the whole team" to a named individual.

Where this model fails

It dies by exception, not by rejection. Nobody argues with least privilege in the review. They adopt it, hit a release deadline six weeks later, and someone is granted an administrator permission set group "just for tonight". Nobody revokes it. Within two quarters you are back where you started with extra ceremony. The counter is not stricter approval, it is speed and visibility: the legitimate step-up path has to be genuinely faster than messaging an admin, and every activation should be published to the team channel rather than a security inbox.

It is downstream of your deploy latency. Removing production Customize Application from functional consultants means a picklist value becomes a deployment. If the pipeline takes forty minutes, the model is worse than what it replaces and the team is right to reject it. Measure p50 deploy time before proposing any of this.

Its assumptions are load-bearing. Whether your full metadata set deploys without Modify All Data is not a footnote, it is the design. Pilot it before you present the model, because one failed deploy in front of the team discredits the whole thing.

Adopt it in this order

Risk reduction is not evenly distributed. Roughly 85 percent of it sits in three moves that cost the team almost no daily friction, because developers rarely work in production anyway.

Week one, production only. This is the thinnest viable platform: the smallest access capability that measurably helps, shipped before anyone argues about the rest. Move the delivery team off System Administrator in production. One read-only permission set group covering Setup read, API access, and metadata retrieve, step-up for everything else, and two sealed break-glass accounts. Leave every sandbox exactly as it is. Nobody's daily work changes, and the blast radius collapses. Build the break-glass accounts properly while you are there, because the recovery paths matter more than the model does when something goes wrong: MFA lockout recovery and break-glass accounts covers the design.

Week two onward, reclassify real-data sandboxes. Every full-copy, partial-copy and pre-prod sandbox gets production rules, because it holds production records. The rules already exist from week one, so the design work is free, but be honest that the effort scales with how many such sandboxes you have and how many people currently work in them. For an org with one full copy this is an afternoon. For an org with a full copy plus several partial copies that developers live in daily, it is the largest behaviour change in the whole plan, because it is the point where day-to-day work actually moves. That is why it follows production rather than leads: production is the bigger risk and the smaller disruption, so it earns trust before you touch where people work.

Month two, split and harden the CI identity. One deployment user per environment, IP-locked, JWT-authenticated, plus the branch protection and pipeline-edit controls that matter more than the Salesforce permissions do. Part 4 covers this in detail.

Everything else, meaning the full tier matrix for T0 through T2, capability set decomposition, muting sets, and automated provisioning, is genuinely good design that should wait for something to force it: an audit finding, a compliance obligation, or a team past roughly twenty-five people. There is no prize for building the destination first.

Working out which phase you are actually at? The hard part is rarely the permission sets. It is the honest inventory: who holds what today, across which orgs, and which of your sandboxes are quietly production. The method is all in this series and the queries are in part 1 and part 4, so you can run it yourself. If you would rather not, CloudCounsel runs it as a fixed-price access posture review.

Frequently Asked Questions

Q: We're a three-person admin team with no developers. Does any of this apply?

A: Almost none of it. Permission set groups per environment tier solve a coordination problem you do not have. What does apply is the underlying habit: use separate named accounts for administrative work rather than doing everything from a daily-driver user that also reads email and runs reports, keep MFA on both, and know who holds Modify All Data and why. That is perhaps a day of work and it captures most of the benefit at your scale. Build the rest only if you grow into it.

Q: How does this change if our admins are an external partner rather than employees?

A: Substantially, because internal teams are governed partly by controls that have nothing to do with permissions: employment contracts, vetting, and an HR system that deactivates accounts on someone's last day. You have none of those over a partner, so technical controls have to carry more weight. Make assignments expire by default rather than persist until removed, since partner staff rotate without telling you. Require that every step-up approver is internal, because external approving external voids the control. Issue accounts in your own identity provider rather than federating from theirs. Never place break-glass credentials externally. Name role groups per partner so audit trail attribution is unambiguous, which matters commercially if you ever dispute quality or scope. And counterintuitively, give partners broader standing access in developer and integration sandboxes, so the genuinely sensitive tiers generate few requests and your internal approvers do not become a bottleneck.

Q: Is 0.1 FTE of ongoing overhead worth it?

A: For the full model, probably not as a pure risk-reduction play if you have never been hurt, because the risk is probabilistic while the overhead is certain and recurring. For the production-only version at three to five hours a month, the argument barely needs having. And if you already carry a compliance obligation that requires answering "who has privileged access and why", a meaningful chunk of that overhead is work you owe anyway and are currently doing badly.

Q: What if we cannot maintain the automation the model assumes?

A: Then do not build it. Every component in the capability table has a documented fallback, and taking the fallback knowingly is a better outcome than deploying automation that decays. The specific trap is post-copy Apex: if nobody on the team maintains production Apex, restrict production and full-copy sandboxes only, and treat that as the permanent design rather than a first phase of something larger.

Key Takeaways

• Size the model to the team: a three-person admin shop and a multi-partner programme need very different amounts of this.
• It scales with orgs and partners, not headcount: eight people across six orgs need more than eight people in one.
• Build only what you can maintain: a component that fails silently is worse than one you never built.
• Choose mechanisms by failure mode: the elegant step-up flow fails by blocking everyone, the crude scheduled job fails by leaving access to be caught later.
• External partners need a different shape, not just less access: expiring assignments, internal-only approvers, per-partner attribution, broader low-tier access.
• Cost it honestly: roughly 15 hours a month for the full model, 3 to 5 for the production-only version that captures most of the benefit.
• Access is a service, not a queue: approval gates feel safer and mostly buy latency. The control is the expiry, the log, and the visibility.
• Cognitive load is the real unit of cost: hours undercount it, because every step-up request is an interruption paid for by the people you most want in flow.
• Access models are abandoned, not rejected: the overhead, not the design, is what kills them.

What's Next?

Recommended Reading:

• Part 4: Deployable permission sets for the metadata, the CI user, and OmniStudio roles
• Part 1: Why your developers don't need Modify All Data if you arrived here first
• Salesforce Data Sovereignty in New Zealand for the offshore partner question
• Team Topologies for Salesforce: The Org Is the Fracture Plane for the org-design layer beneath the platform-team idea used here
• Free Salesforce Event Monitoring: Build a Security Baseline from EventLogFile for the monitoring this model assumes

Action Items:

1. Place your team in the shape table, and cross out everything in the "skip this" column before designing anything.
2. For each component you intend to build, name the person who will maintain it. If you cannot, take the fallback.
3. Measure your median deploy time. It determines whether the functional consultant restriction is viable at all.
4. If you use delivery partners, decide today whether assignments expire by default. It is the single highest-value change on that table.
5. Cost the ongoing overhead in hours and put it in front of whoever owns the team's capacity, before you start.

Resources & References

• Session-Based Permission Set Groups - Salesforce Help
• User Access Policy Considerations - Salesforce Help
• SandboxPostCopy Interface - Apex Reference Guide
• Team Topologies, Matthew Skelton and Manuel Pais (IT Revolution, 2019) - the source for cognitive load, team interaction modes, and the thinnest viable platform

---

About This Guide: Part 3 of the Salesforce Delivery Team Access series. Last updated July 2026. Cost figures are modelled estimates for a team of roughly a dozen across several orgs, not measured data. Substitute your own.

Tags: #salesforce #security #leastprivilege #devops #salesforceadmin