6 Salesforce Tasks Worth Outsourcing, and 5 You Should Never Hand Off
Most "outsource vs. in-house" advice splits Salesforce work by cost per hour or seniority. The split that actually holds up is bounded-and-specialist versus recurring-and-context-dependent - and most of the pain in these arrangements comes from getting that backwards, not from picking the wrong model.
What you’ll learn
- Six categories of Salesforce work that are almost always worth sending outside - because you need the skill rarely, not because the work is hard.
- Five that should stay inside even if you have no in-house developer at all, because losing them costs you institutional judgment, not just hours.
- Why Setup with Agentforce is already eating into the first category, and what stays scarce - and valuable - once it does.
- A real example of where CloudAvant drew this exact line, once on a bounded migration and once on an ongoing operations engagement.
Every "should we outsource Salesforce?" conversation gets asked at the wrong altitude. The real question was never whether to outsource - it's which specific pieces of work belong outside the building, and which ones need someone inside it who can be held accountable next Tuesday, not just during a project. Get that split backwards and the pain shows up no matter which sourcing model you picked on paper: a partner quietly running backlog priorities because nobody internal ever learned to say no to a stakeholder, or a single admin burning three months once every two years relearning a data-migration skill a specialist firm uses weekly.
We've written before about the model-level question itself - in-house team, managed services, or the hybrid most 50-500 employee orgs already run whether they planned to or not. This piece sits one level down: which specific Salesforce tasks are worth outsourcing, task by task, using thresholds that hold up under a second argument - not vibes about what feels like it should be cheaper.
The research for this one turned up a tell. Nearly every "outsource vs. in-house Salesforce admin" guide ranking for this question is written by a firm selling outsourcing, and almost none of them split tasks by how often you actually need the skill - they split by job title and hourly rate, which is a cost argument wearing a strategy costume. A fractional arrangement like Salesforce Expertise as a Service can supply the hands for either side of this list; it doesn't remove the need to decide, task by task, who's accountable for the outcome.
The short answer
In brief: send a task outside when it's bounded (it has a real end state) and specialist (you need the skill rarely enough that building it in-house would be wasted capacity) - a migration, a security-model review, a CPQ rebuild. Keep a task inside, even if you have zero in-house developers, when it's recurring and context-dependent - it requires knowing why the business works the way it does, not just how Salesforce works. Backlog prioritisation, day-to-day user support, and the judgment call on whether a quick production fix is safe right now all fail badly the moment they're handed to someone who isn't there on the days it goes wrong.
The pattern that actually decides it
Most generic advice splits tasks by difficulty - "hard" work goes to a specialist, "easy" work stays in-house. That's the wrong axis. A lot of genuinely hard Salesforce work (a one-time data migration, a security architecture review) is exactly the kind of thing worth sending outside, precisely because it's hard and you'll only need it rarely. Meanwhile a lot of genuinely easy-looking work - triaging this week's support tickets, deciding what the backlog looks at next - fails the moment it leaves the building, not because it's difficult, but because it needs someone who was in the room for every decision that came before it.
| Pattern | What it looks like | Default | Why |
|---|---|---|---|
| Bounded & specialist | A defined start and end state; a skill you need rarely enough that keeping it in-house is wasted capacity | Send it outside | Nobody should build or maintain a skill in-house for something they touch once every two or three years |
| Recurring & context-dependent | Happens weekly or daily; requires knowing why the business works the way it does, not just how Salesforce does | Keep a named owner inside | A partner who closes the ticket and leaves can't carry institutional judgment forward to the next decision |
| Infrequent but context-heavy | A security-model redesign for an org with years of accumulated exceptions; a migration with messy, undocumented history | Bring in the specialist, pair them with an internal owner who stays accountable after they leave | The specialist supplies the skill; the internal owner supplies the memory once the engagement ends |
Salesforce tasks worth outsourcing
1. A one-time data migration or system cutover
A migration off a legacy CRM, or carrying an acquired business onto your Salesforce org, is the clearest case there is: a defined end state, a skill - validated bulk load strategy, Apex batch sizing, rollback planning - that a specialist firm exercises constantly and your team will touch once in a role's entire tenure. Building that muscle in-house for a one-off is capacity you'll never use again.
2. A security and sharing-model architecture review
A sharing model that's quietly accumulated years of exception rules needs an outside, structured review every so often, not a continuous in-house headcount dedicated to it. Shield-level encryption and field audit trails are worth having, but they don't substitute for getting the org-wide defaults, role hierarchy, and sharing rules right in the first place - that design work is exactly the kind of infrequent, high-stakes judgment call worth paying a specialist for when you need it, not a permanent capability you staff for.
3. A CPQ or Revenue Cloud rebuild
Salesforce closing CPQ to new sales is pushing a wave of orgs toward a Revenue Cloud migration they'll do exactly once. That's a specialist, project-shaped piece of work with a genuine end date - a strong candidate to send outside rather than build a standing in-house pricing-engineering capability for a migration you won't repeat.
4. The first build of a new integration
Building the integration is usually fine to outsource. Owning it afterwards is a different question entirely - naming who gets paged when it fails quietly, who inherits it once the builder has moved on. Send the build outside; just don't let "we outsourced the build" quietly become "nobody inside the company understands how this works," which is exactly the pattern behind most of the "the integration keeps breaking" tickets CloudAvant gets called in on.
5. An independent health check or architecture review
An outside, structured look at where an org actually stands - a health check rather than a running architecture function - is close to a textbook case for outsourcing: bounded, specialist, and arguably more honest coming from someone with no stake in defending choices your own team already made. CloudAvant's own Salesforce Health & Roadmap is built around exactly that premise - a fixed-scope assessment, not a retainer you have to keep feeding.
6. Surge capacity around a major release wave
Deciding what counts as a safe pass before a release update takes effect is a judgment call that should stay internal - but the actual hours of running those tests across a large org, during the specific weeks a release wave lands, are exactly the kind of temporary, bounded volume spike that's wasteful to staff for year-round. Bring in extra hands for the surge; keep the judgment call itself with whoever already owns it the rest of the year.
Salesforce tasks that should never leave the building
7. Day-to-day user support and ticket triage
Not because it's hard - because it's the thing that teaches whoever does it which fields sales actually relies on, which "urgent" requests are genuinely urgent, and which workaround somebody built three years ago that nobody can explain anymore. Hand this fully to a rotating cast of external tickets-only support and you've traded a cost line for exactly the single point of failure you were trying to avoid - you just moved it outside the building, where you can see it even less.
8. Backlog prioritisation
Prioritising the backlog is a business judgment dressed up as a technical one - which complaint is actually costing revenue versus which one is loudest this week. An external partner can execute against a prioritised backlog extremely well. Asking them to set the priorities themselves, because nobody internal has the standing or the time, is how a Salesforce programme ends up optimised for whichever client contact shouts the most convincingly, not for what the business actually needs next.
9. The week-to-week stewardship of the permission model
The one-off review above is worth outsourcing. The ongoing decisions - does this new hire's role need its own permission set, has this profile quietly become a dumping ground for one-off exceptions - need someone who actually watches the model drift over time, not someone who audits it once a year and leaves. Access creep is slow by nature; it only gets caught by whoever is present for every small decision that adds up to it.
10. The "is this safe to ship right now" call
Deciding whether a quick fix directly in production is acceptable right now, or needs the full pipeline, depends on context an outside partner usually doesn't have in the moment: how fragile this particular object's automation has become, what else is mid-deployment, who's actually online to catch it if it's wrong. This is a live risk judgment, not a configuration task - it belongs with whoever carries the consequence of getting it wrong.
11. Turning a stakeholder's request into actual scope
"Can you just add a field for X" is rarely the real request, and figuring out what is - and sometimes saying no outright - requires standing inside the organisation that an external resource, however senior, has to earn request by request. This is the task most often skipped in outsourcing conversations because it doesn't look like Salesforce work at all. It's the task that determines whether everything downstream of it gets built well.
What Agentforce is already changing about this list
Salesforce's own admin blog describes Setup with Agentforce as already handling common admin tasks directly from a conversational interface - user management, troubleshooting, custom object and field creation. If that holds up at scale, it's eating precisely the low end of the "bounded and specialist, but genuinely tedious" category: not the judgment-heavy items above, but the routine execution work that used to be the easiest argument for outsourcing in the first place.
There's early, if indirect, evidence this is already pressuring the economics of Salesforce services work generally. One 2026 analysis citing the SPI Professional Services Maturity Benchmark - a survey of 403 professional-services firms - reported EBITDA margin down to 9.8%, the lowest in five years, with billable utilisation at 68.9% against a 75% benchmark firms consider healthy. That's margin pressure consistent with AI eating routine execution hours, not proof of it - treat it as a forecast the data supports, not an observed outcome. Either way, the practical implication for the list above doesn't change: as routine execution gets automated, the tasks that stay genuinely scarce - and worth paying for, whether in-house or outsourced - are judgment calls, not keystrokes. That's an argument for investing more in the eleven decisions above, not fewer.
From the field
CloudAvant's work migrating a newly acquired Mastercard subsidiary from SAP C4C onto Service Cloud sat squarely in the "send it outside" column: a six-person team of developers and QA engineers, brought in for a bounded data migration with a defined end state, handed back to the business once it was stable. The managed Salesforce operations engagement run across a multi-region enterprise's EMEA business sits on the other side of the table above, even though CloudAvant was still the external party doing the work - because the engagement was structured as a standing, accountable team coordinating production support and Salesforce-SAP integration issues continuously, not a bounded project handed back at the end. The task decides the shape of the engagement; the org chart alone doesn't.
Questions worth asking about this list
What about a task that's both infrequent and needs deep context?
That's the third row in the table above, and it's common - a security redesign for an org with years of undocumented exceptions, a migration where the source system's quirks are only known to one departing employee. Bring in the specialist for the skill, but pair them with a named internal owner from day one who stays accountable once the engagement ends, rather than discovering after the fact that the only person who understood the new design has also left the building.
Can one partner handle both the bounded work and the standing ownership role?
Yes, and it's a common, legitimate shape - the managed-operations example above is exactly that. What has to be explicit is which mode you're in for a given piece of work: a bounded engagement with a close date, or a standing commitment with continuous accountability. Where this goes wrong isn't the hybrid itself; it's leaving that distinction implicit, so a project-shaped engagement quietly becomes the org's only source of institutional memory with no plan for what happens when it ends.
What if we don't have an internal admin at all?
Then "keep it inside" means naming a specific person - often someone in ops, sales, or finance with no Salesforce title at all - as the accountable owner for the five recurring items above, even if a partner executes most of the actual configuration. The failure mode to avoid isn't "no internal Salesforce skill"; it's no internal owner of judgment, which is a different and more expensive gap to discover later.
The bottom line
The sourcing model you pick matters less than most comparisons suggest. What actually determines whether a Salesforce operating model holds up under pressure is whether the eleven items above landed on the right side of the line - not whether the org chart says "in-house team" or "managed services" at the top. If you're not sure which of your own recurring tasks have quietly drifted to whoever happened to be available, rather than whoever should actually own them, that's worth talking through with an architect before the gap surfaces as an incident instead of a decision.
Not sure which side of this list your own backlog falls on?
Written by CloudAvant Team - Senior Salesforce consultants and architects with hands-on enterprise delivery experience across Sales Cloud, Service Cloud, Experience Cloud, and complex multi-region implementations. More about CloudAvant.
Related Insights