The question arrives as a budget question. An integration platform costs a subscription and a few afternoons; custom integration costs a developer and a month. Put that way, the platform wins every time, and the company builds all its connections as flows until one of them fails in a way nobody can see.
It is not a budget question. It is a shape question. Connections come in shapes, an integration platform like Zoho Flow handles one shape very well, and three shapes it does not. Choose by shape, connection by connection, and both the cheap and the expensive tool end up in the right place.
A flow is an event and a sequence of steps. Something happened in one system; do these things in another. A deal closes in the CRM, create the customer in the accounting system and the onboarding project in the project tool. A form is submitted, create the lead and notify the owner. An invoice is paid, update the deal.
For this shape the platform is the right tool and it is not close. The trigger is native, the steps are drag-and-drop, the mapping between the two records is visible on screen, and a change takes minutes. Most of the connections in a mid-market estate are this shape, which is why the platform earns its subscription many times over. We compared Zoho Flow with Zapier separately; for event-shaped work either does the job and Flow has the advantage of living inside the suite.
The event shape has one property that makes it safe for a flow: each run is independent. One deal, one customer, one project. If a run fails, one record is affected, the platform logs it, and someone re-runs it. Nothing else depends on it.
The failures happen when a connection has a different shape and the company builds it as a flow anyway, because the flow was there.
The set. Compare the customers in the sales system to the customers in the accounting system and fix the differences. This is not an event; nothing happened. It is two lists, a join, and a set of corrections, run on a schedule. Built as a flow, it becomes a thousand individual runs that each look up one record, time out on the long ones, and leave the two systems half-reconciled with no record of where the run stopped. Reconciliation is a program with a cursor, a transaction log and a report of what it changed, and that is code.
The transaction. Create the order, reserve the stock, and raise the invoice, all of which must succeed together or none of them. A flow runs its steps in sequence and stops on the first failure, leaving an order with no stock reservation, which to the warehouse looks like an order it can ship. The platform has no concept of rolling back step two because step three failed. Code does, and for a connection where a half-done state costs money, the rollback is the whole value.
The decision. Choose the carrier for this load, the supplier for this purchase order, the next step for this ticket, based on history, limits, prices and whatever else the records hold. A flow can branch on a field; it cannot evaluate a situation. When the connection has to decide rather than copy, it is a rule engine or an agent with written limits, and either way it is code with a specification behind it.
Three shapes: sets, transactions, decisions. They are a minority of the connections and most of the integration budget, which is why the budget framing misleads. The expensive connections are expensive because of their shape, not their tool.
Take the connection list, the one from the three decisions that come before any connector, and add a column: shape. For each connection, ask whether it is triggered by one event and acts on one record, or whether it compares sets, must succeed as a unit, or has to decide. The first group goes to the platform. The other three go to code.
Then ask one more question of the event-shaped group: does any of them depend on another connection having run first? A flow that creates the invoice from the deal depends on the flow that created the customer from the account, and if the second runs before the first, the invoice has no customer. Dependencies between flows are the quiet failure mode of a platform-only estate, and the fix is either ordering the triggers deliberately or moving the dependent pair into one coded connection.
The sorted list is usually lopsided: fifteen flows and four coded connections. That is the right ratio. A company with forty flows and no code has probably built a reconciliation as flows and does not know it yet. A company with every connection in code paid a month each for fifteen afternoons of work.
A deal closes and the customer must exist in the accounting system. Event, one record, no dependency on anything that has not already happened by the time the deal closes. That is a flow, and it should take an afternoon including the test.
Every night, the stock levels in the inventory system must agree with the levels the e-commerce site is showing, and where they disagree the site must be corrected and the discrepancy logged for the warehouse. Set, comparison, correction, report, on a schedule. Built as flows, this is one run per product, several thousand runs a night, each one a separate lookup, and a product that fails halfway stays wrong until someone notices the site sold stock it did not have. Built as code, it is one job that reads both lists, produces the differences, applies them in a batch and writes one summary line. The second connection is not harder because it touches more records; it is a different shape, and the shape is what decides the tool.
Whatever the tool, every connection needs the same monitoring, and this is where the platform-only estate is weakest. A flow that fails sends an email to the person who built it, who may have left. A coded connection logs to wherever the developer pointed it. Neither is a system of record for whether the business's connections are healthy.
Give every connection, flow or code, one place to report: ran, how many records, how many failed, which ones. One dashboard, read weekly by a named person. The integration platform's own history is fine for a flow's detail; the summary belongs where someone will look. A connection nobody watches is a connection that is already broken, and the business finds out from a customer.
Zoho Flow is enough for the event-shaped majority and should be used for it, without apology and without a developer. It is not enough for sets, transactions and decisions, and the companies that try it find out through half-synced systems and orders that shipped without stock. Code is the right tool for those three, and only those three.
The skill is in the sorting, and it has to be done before the first connection is built, because a reconciliation that starts life as a flow is hard to unbuild. Discovery is no-risk: we sort your connection inventory by shape, tell you which four need code, and you pay only if you go ahead.
The ERP Readiness Review is a 90-minute working session plus a written scorecard across master data quality, documented exceptions, integration scope and data ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
Start a Zoho One trial through our sign-up, or tag us as your Zoho partner for free consulting time every month.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
