When an integration platform is enough, and when custom integration is worth building

Two SaaS products can often be connected in an afternoon with Zapier or Power Automate. Copying a lead, sending a notification or asking someone to approve a document is exactly the kind of work those platforms exist to do. Building and operating a custom service for that work is often a worse use of time.

The decision changes when the same style of workflow starts moving money, keeping customer records in step, or becoming the only path between two systems. At that point a connector is not enough on its own. The organisation has to live with how the integration behaves when the destination is slow, the event arrives twice, or only half the work succeeds.

When a platform is the right tool

Zapier and Power Automate are legitimate software platforms. A well-designed Power Automate flow can run an important business process. A developer can also build a brittle integration that nobody can operate. Choosing a method is not a statement of how serious the work is.

A platform is often the sensible answer when the systems already have supported connectors, the workflow is easy to follow, there is little lasting state, a delay of seconds or minutes is acceptable, and a failed run is easy to see and try again. It is especially useful when the people who understand the process can see and change the workflow themselves, when the organisation does not want to operate middleware, and when the cost of custom engineering would exceed the value of owning the implementation.

Notifications, approval flows, straightforward CRM updates, document routing, simple lead handoffs, form-to-system work, internal administration and scheduled reporting steps all sit in that range. They are not unimportant because a low-code tool can handle them. A process can be commercially useful without deserving a service that someone has to host, patch and monitor.

That is the same reasoning as treating custom software as something you take on when a product will not do the job, not because writing software is possible. A few hundred lines of integration code is still software. It needs hosting, deployments, monitoring, authentication, secrets, retries, error queues, logging, schema and API changes, security patches, upgrades, support and documentation. If Zapier or Power Automate already provides the required behaviour, taking all of that on may be wasteful.

What the process has to survive

Before choosing Zapier, Power Automate, Logic Apps, a custom service or code inside an application, it helps to know what the process actually does: which event starts it, which system owns the information, what must happen next and how quickly, and what should happen if the destination is unavailable, the same event arrives twice, or only half the steps succeed. Someone also has to notice failure, replay the work, and keep enough evidence afterwards.

Those questions are not a scorecard for buying software. They are a way of seeing whether the integration method matches the operational requirement. Automation often describes the workflow: when this happens, do that. Integration is broader. It concerns how systems exchange information and remain consistent. A Zapier or Power Automate flow can be both.

Volume is part of that picture and a poor sole test. A few dozen administrative events a day with complex state and financial consequences can need more controlled implementation than a high-volume notification stream that is cheap to replay. Burstiness, latency, connector quality, retry behaviour and the cost of being wrong all matter more than a daily count.

Complexity is not the number of steps on a canvas either. Branching state, waiting for an external event, two systems changing the same record, compensation after a partial failure, long-running work, ordering, concurrency and reconciliation can hide inside a visually simple flow. A custom service with hundreds of lines can still be conceptually simple. There is no useful universal threshold at which a Zap or flow should be rewritten.

Failure handling is often what separates a working demonstration from something the organisation can operate. The destination API can go offline, credentials can expire, a schema or connector can change, validation can fail, step three of five can succeed while the rest does not, a request can time out, the same event can be delivered again, the workflow can be throttled, or the person who built it can leave. A flow that copied a record once does not answer those cases.

Acknowledgement, limits and delayed work

Zapier documents a useful example of a distinction that applies to almost every integration. During periods of high webhook activity, it may return HTTP 200 and process the webhook several minutes later. The sending application can reasonably believe its request was accepted. That tells you the platform received the request. It does not tell you that the downstream business process finished at that moment.

That is ordinary queueing, not a product failure. Asynchronous processing is how most integrations absorb a burst of work. The organisation still needs to understand the platform’s delivery behaviour. A successful response and a completed process are different claims.

Both Zapier and Power Automate document operational limits. Work can be delayed or held. Connectors have their own throttling. Capacity depends on plan and licence. Sustained over-limit behaviour can change how a workflow runs. Microsoft documents that a Power Automate flow which remains consistently throttled can eventually be turned off. The same documentation, and the product’s limits guidance, also describe continuously failing flows being disabled. Every managed service has limits. Those limits have to be compatible with the process.

Retries make a second distinction visible. Integrations retry. A payment, invoice, user account or booking should not be created twice merely because delivery was attempted again. Custom integrations can implement that explicitly. Some platforms and destination APIs already help. Once duplicate handling becomes central to correctness, the organisation needs to know exactly what its platform and destination APIs guarantee.

Reconciliation is the same idea at a later moment. If one system believes an order, payment, enrolment or CRM change succeeded and another does not, how is that disagreement found? A mature integration may need comparison jobs, exception queues, replay, durable history and a way for someone to correct the record. Zapier and Power Automate can implement parts of that. As the consequence of disagreement rises, the operational model matters more than the existence of a connector.

Who owns the flow, and what custom actually costs

Power Automate makes the ownership question easy to see. A flow often starts as something one employee built to make their own work easier. Later a team, finance, operations, customers or another system begins to rely on it. The organisation then needs to know who owns it, whose connections it uses, who can change it, who receives failures, how it is documented, and what happens when the original maker leaves.

The same thing happens with Zapier, scripts, spreadsheets and custom applications. The problem is operational ownership, not the product. An automation that nobody can explain is a continuity risk whether it lives in a platform or in a repository.

Security sits next to that. Integration tools commonly need access to CRM, finance, email, documents, customer data or internal APIs. The decision includes what credentials are stored, what those credentials can do, whether they belong to a person or a service account, who can change the workflow, and what audit history exists. Custom code does not automatically provide better security. A badly managed service with a long-lived secret can be worse.

Cost is also easy to mis-compare. A platform charges for subscriptions, usage, premium connectors, task or request volume, and higher plans. Custom work charges for engineering, hosting, monitoring, maintenance, incident support, API changes, upgrades, security work and the people who still understand it. A platform that looks expensive per transaction can still be cheaper than owning the software. High usage can reverse that. The useful work is naming those components, not inventing a break-even number.

Using Zapier or Power Automate means the process relies on platform availability, pricing, connector behaviour, product changes and supported integrations. Custom software relies on cloud providers, libraries, frameworks, other vendors’ APIs and internal knowledge. Dependency is a problem when it is not understood. It is not automatically a reason to build.

Mixing the two, and changing the decision later

Microsoft’s own documentation already refuses a single-product answer. It positions Power Automate for simpler, little-code business integrations, Logic Apps for more advanced enterprise and hybrid workflow work, and Azure Functions for code-first execution. It also says those services can call each other. That is vendor positioning, not a ranking, and it is evidence that even Microsoft treats Power Automate as one layer.

Hybrid arrangements are therefore ordinary. Power Automate can handle approvals while custom middleware or Logic Apps keeps transactional records in step. Zapier can receive a SaaS trigger and call a controlled internal API. A custom path can remain authoritative while low-code sends notifications. Those are examples, not a recommended stack. The dividing line should follow responsibility and operational need. Not every process should become hybrid.

A Zap or Power Automate flow can be exactly the right first implementation. Volume grows, more branches appear, more systems are added, customers begin depending on the result, and the cost of failure increases. Moving part of that work into software the organisation operates later does not prove the first implementation was a mistake. Architecture can change as consequence changes.

The opposite happens too. Custom middleware sometimes exists only because a suitable connector or platform feature did not exist when it was written. A later platform capability can make that code unnecessary. Defending custom software because someone already paid for it is a different decision from asking whether it is still the right one.

A process matters because being wrong or unavailable has an actual effect: orders stop, people cannot access a service, financial records disagree, compliance evidence is lost, staff have to reconstruct transactions by hand, or customers receive the wrong outcome. Matching the implementation to that behaviour, including failure, retry and later change, is the useful decision. Where a platform already provides it, the platform is often the cheaper thing to operate. Where it does not, owning more of the implementation can be justified by the requirement rather than by a preference for code.