Do You Need a Full-Time Salesforce Architect? The 7 Decisions That Answer It

Picture a hypothetical 180-person org asking whether it needs to hire a Salesforce architect (an illustrative scenario, not a description of a specific client). By the time the question is asked, the answer has already gotten complicated: in the previous three weeks, someone on the team has added a sharing rule exception to unblock a deal, pointed a new integration at the same Account fields an existing nightly batch job already wrote to, and floated splitting a business unit into its own org to dodge a licensing conflict. Nobody has flagged any of the three as an architecture decision. They just look like normal work.

SalesforceBen's 2026 architect survey found the most common Salesforce team shape, two years running, is several developers, a few admins, and one architect - roughly a third of respondents each year. Around three-quarters of those one-architect teams still bring in external partners or systems integrators for at least some of the delivery work. Sit with that for a second: even orgs that answered the headcount question - how many Salesforce people an org actually needs - by hiring an architect mostly didn't stop buying outside help. Headcount and review discipline are different problems. A Salesforce Health & Roadmap review exists specifically to find the decisions that shipped without either.

The short answer

In brief: probably not, at least not as a first move. What predicts whether an org needs architectural authority isn't team size, ticket volume, or a round number of licensed users - it's whether specific, identifiable decisions are being made by whoever happened to be available that week rather than whoever could see the consequence. Below are seven of those decisions. If none of them describe anything that's happened at your org in the last twelve months, you're probably fine without dedicated architecture capacity. If two or three do, the gap isn't a missing hire - it's a missing review step, and a fractional or outsourced architect closes that gap without the overhead of a full-time seat somebody then has to keep busy.

What the 2026 architect survey data actually shows

The survey numbers back up something CloudAvant sees directly in client orgs: hiring an architect and fixing the underlying review gap are two different projects, and plenty of teams only do the first one.

None of that means one architect is the wrong answer, or that buying outside help is a failure state. A lot of teams that look settled on paper - one named architect, a defined team - are still paying for external architecture capacity on purpose, because the two things cover different gaps. CloudAvant's own Salesforce Expertise as a Service model is built around the same assumption: reserved access to senior architecture and engineering capability sized to what an org actually needs that quarter, not a fixed headcount somebody has to keep permanently busy to justify.

The seven decisions that actually need architectural review

Team size doesn't predict any of this well. The decision itself does. Here are seven moments where skipping architectural review tends to be expensive later, even though each one, in isolation, looks like a routine call.

1. Two systems are about to write to the same Salesforce object

Whoever builds the second integration can almost always see their own write pattern. What they usually can't see, because nobody asked them to check, is the existing batch job, trigger, or Flow that already owns the same fields - until both fire in the same transaction and one silently overwrites the other. This is the single most common gap CloudAvant finds reviewing Salesforce-SAP integrations: not that either system is badly built, but that nobody owned the question of which system's write should win. Direct API integration and MuleSoft solve this differently, and picking between them is itself an architecture decision - but it's the wrong moment to be making that choice for the first time under delivery pressure.

2. A sharing or security exception is being scoped to solve one team's problem

The request almost always arrives narrow: one rep needs to see records they currently can't. The fix that gets shipped is rarely that narrow - a sharing rule or permission set exception written to solve the specific ticket often ends up readable by, or inherited by, people well outside the team that asked for it. Sharing model decisions are exactly the kind that quietly turn into technical debt a year later, because nobody revisits them once the original ticket closes. The question worth asking before shipping the fix isn't whether it solves the ticket - it's who else this now applies to, and whether anyone meant for that.

3. Someone floats splitting into multiple orgs, or merging two into one

This decision usually arrives dressed as a licensing or M&A question, not an architecture one - which is exactly why it needs architectural input before anyone commits to it. Single org versus multi-org is one of the most expensive calls a Salesforce programme makes, and it's rarely revisited once users, automation, and integrations have accumulated on either side of the split. If the person driving the business case has never had to maintain a multi-org Salesforce environment day to day, get someone who has into the room before the decision, not after it.

4. A build-vs-buy call has governor-limit or data-volume implications beyond the immediate feature

An AppExchange package evaluation usually gets scored on price, feature fit, and vendor reputation. What it doesn't usually get scored on is what the package actually does at your org's real record volume and existing automation load - and that's the part of a build-vs-buy decision that actually predicts whether it holds up. A package that runs fine at 50,000 records can start competing for the same governor limits as your existing automation at 2 million. Someone needs to check that before the contract is signed, not after the first bulk load times out.

5. New automation depends on an execution order nobody has mapped

Flow and Apex triggers on the same object fire in a specific, documented order - but documented doesn't mean anyone building the fifth piece of automation on that object has actually read it recently. AI-assisted Flow generation makes this worse, not better, because it's very good at producing automation that passes its own test and very bad at knowing what else already runs on the same record. The review that catches this isn't a code review of the new automation in isolation - it's someone asking what else touches this object, in what order, before the fifth piece gets added to the fourth.

6. The decision would take more than a quarter to reverse if it's wrong

Data model choices, sharing model choices, and integration patterns share one trait that makes them architecture decisions by definition: getting them wrong doesn't cost a sprint, it costs a programme. Fix, rebuild, or reimplement is the decision an org eventually has to make once enough of these accumulate without review - and by the time that conversation happens, the original decision is usually long forgotten. The test is simple to apply in the moment, even though it's rarely applied: if reversing this decision would take more than a quarter, it needed more than one person's sign-off to make it in the first place.

7. Nobody currently at the company can explain why an existing design choice was made

This is the quietest version of the problem, and the most common one CloudAvant finds in a Salesforce Health & Roadmap review: a sharing rule, an integration pattern, or an object relationship that clearly took real thought to build, with nobody left who can say what problem it was solving. It's a close cousin of the single-point-of-failure risk an org takes on when one admin holds all the undocumented context - except here the risk already materialised, the person already left, and what's left behind is a design nobody feels safe changing because nobody can prove it's safe to change. The fix isn't heroic reverse-engineering after the fact. It's a habit, going forward: every non-obvious design decision gets one sentence of written rationale, wherever the team already documents things.

Who makes each call by default, and who actually should

Put plainly, the failure mode across all seven is the same: the decision gets made by whoever is already in the room, not by whoever has the context to see what else it touches.

One of CloudAvant's own engagements shows what this looks like when the review happens on purpose, rather than after the fact.

Hire, outsource, or fractional: how to actually decide

Say two or three of the seven signals above describe your org. The next question is who should own the review - and "hire a full-time architect" is only one of three honest answers, not automatically the right one.

Hiring makes sense when architecture-level decisions are now a weekly occurrence, not a quarterly one, and the org is large or complex enough - multiple clouds, multiple regions, a continuous stream of integration work - that one person can stay usefully busy doing nothing else. Below that threshold, a full-time architect is either underused or, more often, gets pulled into delivery work because there isn't enough purely architectural work to fill the role, which defeats the purpose of hiring one in the first place. Outsourcing the whole relationship to a systems integrator works when a large, time-boxed programme needs architecture and delivery bundled together. Fractional or on-demand architecture review - CloudAvant's own model under Salesforce Expertise as a Service - tends to fit the gap in between: an org that's past guessing its way through these decisions but not yet running enough concurrent architecture-level work to justify a dedicated seat.

The honest failure mode worth naming: a lot of orgs hire a full-time architect specifically because they don't trust anyone to flag these seven decisions consistently, and then that architect spends most of their time on delivery work anyway, because nothing forces the decisions to actually surface. Hiring doesn't fix a missing review step by itself. A named review trigger does - something as simple as "any change touching a shared object, the sharing model, or an integration gets a second set of eyes before it ships" - regardless of whether that second set of eyes is a new hire, a fractional architect, or whoever currently holds the most context.

Questions worth answering before you post the job listing

Can a senior developer just take on these decisions instead of hiring an architect?

Often, yes - the architect title isn't what makes the review happen, the habit of asking the question is. A senior developer with enough tenure to know the org's history and enough authority to say "not yet" to a delivery deadline can cover most of the seven signals above. What breaks this is scale: once two or three senior people are each making calls like this independently, without comparing notes, you've recreated the exact gap a dedicated review role exists to close - just with more people involved in missing it.

If we just hire one architect, does that solve it?

Not automatically. Around three-quarters of orgs with exactly that setup - several developers, a few admins, one architect - still buy outside architecture help, according to SalesforceBen's 2026 survey. Hiring answers the headcount question. It doesn't automatically answer whether the seven decision types above actually get routed to that person before they ship, which depends on process and habit more than on the org chart.

How is this different from the admin-vs-developer-vs-architect question?

That comparison answers which role fits a given piece of work - configuration, custom build, or design authority. This piece answers a narrower, earlier question: how do you recognise that a specific decision needs design authority at all, regardless of who ends up providing it. An org can get the first question right role by role and still miss this one, because the decisions that need review rarely announce themselves as architecture work when they show up.

What if nobody at our org currently has the context to do this review?

That's a legitimate answer to the original question, and it's a cheaper problem to fix than a hiring mistake. An outside architecture review - a one-off engagement rather than a seat on the team - can establish the baseline (what's actually built, what depends on what) and hand back a framework for the next person to apply internally. CloudAvant structures its Health & Roadmap engagements this way on purpose: a client can act on the findings internally, with their existing partner, or with CloudAvant, with no obligation attached to the engagement itself.

The bottom line

Most Salesforce orgs don't have a hiring problem. They have a visibility problem - these seven decisions already happen, on a schedule nobody controls, whether or not anyone with architectural context is in the room for them. Hiring a full-time architect is the expensive way to guarantee someone's in the room. A named review trigger, backed by fractional or on-demand architecture capacity when it's actually needed, usually gets there faster and cheaper. If you're not sure which of the last year's decisions at your org fell into one of these seven categories, that's precisely what a Salesforce Health & Roadmap review is built to surface. Talk to us if you'd rather find out on purpose than find out the hard way.