Custom Salesforce Integration vs Zapier: When to Build

The choice between a custom Salesforce integration and Zapier gets framed as a budget question, and it isn’t one. It’s a question about where your business rules live. Zapier is genuinely good at moving a record from one system to another. It was never built to hold the logic that decides which record, for whom, and under what exception — and the moment your integration starts holding that kind of logic, it stops being a pipe and quietly becomes an application that nobody can test, report on, or explain.

Most orgs cross that line without noticing. This is how to tell when you have.

What middleware is actually good at

Start with the honest part, because the anti-Zapier take is usually overcooked. Middleware’s real advantage is breadth. Zapier, Make, and the rest connect to hundreds of applications you would never write a connector for, and they let somebody who has never opened a developer console wire two systems together in an afternoon. That is a genuine capability, and it is not one a custom build competes with.

If your automation is a straight line — a form submission creates a Contact, a closed-won Opportunity posts to a channel, a new Lead pings a Slack room — middleware is the correct answer and a custom build is over-engineering. There is no conditional business meaning in those flows. They are plumbing, and plumbing is exactly what a connector is for.

Keep those Zaps. Nothing below is an argument for ripping out the ones that work.

The line: moving records versus holding rules

The dividing line is not complexity and it is not volume. It’s whether the automation carries a decision.

“When a Lead is created, send it to Slack” is a pipe. “When a Lead is created, unless the account already exists, and unless it came from the partner form, route it to the territory owner, or to the regional queue if the owner is out, and escalate if nobody touches it in an hour” is an application. It has branches, exceptions, and an owner who will be asked to defend it in a QBR.

The tell is simple: can you explain the automation to a new hire without opening the editor? If you have to screen-share the canvas and trace the paths, the rule doesn’t live in a rule anymore. It lives in a diagram. This is the same failure mode that makes Salesforce approvals outgrow Flow — the business states its policy as a sentence with an unless in it, and the tool makes you draw it as a path.

Symptom one: the Zap that grew a branch tree

The first thing you’ll see is a multi-step Zap with filters and paths that somebody added on a Tuesday eighteen months ago and then left the company.

There is no meaningful version history. There is no test that fails when the logic breaks. There is no way to ask “what changed in this automation last quarter” and get an answer you’d put in front of an auditor. And the branch conditions — the actual business policy — are typed into form fields in a browser tab, which means the org’s routing rules are not in the org.

That’s the part that matters. It isn’t that a connector can’t express the logic. It’s that once it does, the logic is somewhere your CRM can’t see it. The same argument decides Flow versus Apex inside Salesforce, and it decides this one outside it.

Symptom two: latency you can’t design around

Most connector triggers work by polling — the platform periodically asks the app for new data. Zapier documents the interval as a function of plan: every 15 minutes on Free, every 2 minutes on Professional, and every 1 minute on Team and Enterprise (Zapier, “How Zap triggers work”). Instant triggers exist where the source app supports webhooks, and where they’re available they’re the right choice.

For a lot of work, a two-minute delay is invisible. For speed-to-lead it isn’t — a round-robin assignment that lands two minutes late has already lost the window it was built to protect, and no amount of tuning inside the connector closes a gap that’s structural.

Salesforce’s own answer to this is push, not poll. Change Data Capture publishes near-real-time events for record creation, update, deletion, and undeletion, and Salesforce’s guidance is explicit: use it “instead of doing periodic exports and imports of data or repeated API calls” (Change Data Capture Developer Guide). A custom integration gets to subscribe to that stream. A polling connector, by definition, does not.

Symptom three: the API budget nobody planned for

Polling is not free, and the bill doesn’t arrive as money — it arrives as headroom.

A paid Salesforce org has a daily API request allocation. Enterprise Edition starts at 100,000 requests per 24-hour period and scales with the licenses the org is provisioned with, with additional calls purchasable in increments from 200 to 10,000 (Salesforce Developers, “API Limits and Monitoring Your API Usage”). Exceed it and requests come back with an HTTP 403 and a REQUEST_LIMIT_EXCEEDED error code.

Here’s the uncomfortable property of that failure: it isn’t scoped to the automation that caused it. When the allocation is gone, it’s gone for everything authenticating through the API — your other integrations, your reporting extracts, your data tooling. And a polling connector consumes that allocation continuously, at a rate set by the plan tier, whether or not anything in the org actually changed. Ten Zaps polling an object every two minutes is a constant background draw on a shared resource, and it is nearly always invisible until the day something unrelated breaks.

Symptom four: nobody can answer “why did this record change?”

Field history will tell you that Owner changed from one user to another at 14:02, by the integration user. It will not tell you which rule fired, which branch it took, or what the input looked like.

When the rules live in a third-party account that two people can log into, the question “why did this record change?” has no answer inside Salesforce. Ops asks the admin, the admin asks whoever built the Zap, and the reconstruction is somebody reading a canvas out loud. That’s survivable at three automations. It is not survivable at thirty, and it’s actively dangerous anywhere the automation touches something with consequences — pricing, entitlement, duplicate handling on conversion, commission-relevant ownership.

What the custom version actually looks like

“Custom integration” sounds like a platform project. Built well, it’s four small pieces:

A subscription instead of a poll. Change Data Capture or a platform event, so the org tells you when something happened rather than being asked 720 times a day whether it did.

The rule expressed as data, not as a drawing. Custom metadata or a small routing object holding the territory table, the exception list, the thresholds. Ops edits a row; nobody edits a canvas. This is the single highest-leverage difference, and it’s the one people skip.

An outbound path with real credentials handling. Named Credentials for the callout, retry behavior you chose deliberately, and a defined answer for what happens when the far end is down for nine minutes.

A place where failures land. A log or error object inside Salesforce, so a failed sync is a record ops can see, filter, report on, and re-drive — instead of an email from a connector that somebody has a filter for.

That’s a build, but it’s a contained one, and it sits alongside the other custom Salesforce integrations worth owning rather than renting. It’s also a different decision from the AppExchange buy-versus-build question, where you’re evaluating somebody’s finished product. Here you’re deciding where your own logic is allowed to live.

The honest scorecard

	Middleware (Zapier, Make)	Custom build in the org
Breadth of endpoints	Hundreds of apps, immediately	Only what you build
Time to first working version	An afternoon	Longer — but hours, not a quarter
Latency	Poll interval, or instant where webhooks exist	Event-driven, near-real-time
API consumption	Continuous background draw	Only when something changes
Where the logic lives	In the connector’s account	In the org, as data
Who can change it	Whoever has the login	Whoever has org permissions
Auditability	Outside Salesforce	Inside Salesforce, reportable
When it breaks	An email, and a canvas to read	A record, filterable and re-drivable

Read that table honestly and middleware wins the top two rows outright. Those two rows are why it’s the right call for most of what most orgs automate. The bottom five are why it’s the wrong call for the handful of automations that actually carry policy.

Why orgs stay past the line

Because “custom” used to mean a project.

It meant scoping, a statement of work, a developer with Salesforce experience, a sandbox, a deployment window, and a wait measured in weeks. Against that, bending the Zap one more time was the rational choice — not the lazy one. The people making that call were doing correct math with the options they had. It’s the same math that kept teams on no-code past its ceiling for years.

What changed is who does the building. When your AI can develop directly in the org — read the schema, write the subscriber and the config object, run the tests, deploy — the custom option stops being a quarter and starts being an afternoon. That’s the whole premise behind making your AI your CRM developer, and it’s why the line between “keep the Zap” and “build it properly” has moved.

The obvious objection is trust, and it’s the right objection. The answer isn’t that the AI can’t make mistakes — it’s that the work is visible and recoverable: deploys go to a sandbox with tests first, every change is logged with who and when, and a snapshot is taken before the deploy so a bad change is something you roll back rather than something you investigate. That’s the safety layer in one paragraph; the deep dive is there if you want it. Pricing is flat per Sentinel and is covered on a short demo call.

How to draw the line this week

Don’t audit everything. Do this instead.

Open your connector’s task list and write, in one plain sentence, what each automation decides. Not what it does — what it decides. Most will come out as “it copies a thing to another thing,” and those are fine forever.

Then flag every sentence containing the word unless, or more than one and. Those are the automations holding policy, and they’re the ones where the connector is now the least accountable part of your stack. Rank them by what happens when they’re wrong or late, take the top one, and build that one properly.

If you want to see what “properly” looks like in your own org before committing to anything, pointing an AI at a sandbox and asking it to read your existing automations back to you in English is a cheap first move — connecting Claude to your Salesforce org is an afternoon, and the inventory alone usually surfaces two rules nobody knew were still running. From there, Salesforce automation without hiring a developer is the practical next step.

Book a Demo Call and bring the one Zap you’re afraid to touch. That’s the one worth talking about.