Zoho Flow or Code: Sort Every Connection by Shape.

When a company has to connect two systems, the question arrives as a budget question. An integration platform costs a subscription and a few afternoons. Custom code costs a developer and a month. Put that way, the platform wins every time, and the company builds every connection as a flow until one of them fails in a way nobody can see. It is not a budget question. It is a question about the shape of the connection. This video shows the four shapes and which tool each one belongs to.

Everything on screen is a mock demo with sample data. A flow is an event and a sequence of steps. Something happened in one system, so do these things in another. A deal closes in Zoho CRM: create the customer in Zoho Books, create the onboarding project, notify the owner. A form is submitted: create the lead and tell the right person. For this shape the platform is the right tool, and it is not close. The trigger is built in, the steps are dragged into place, the mapping between the two records is visible on screen, and a change takes minutes.

Most of the connections in a mid-sized company are this shape, which is why the platform earns its subscription many times over. It is also safe, because each run is independent: one deal, one customer, one project. If a run fails, one record is affected, the platform logs it, and someone runs it again. The first shape a flow is not built for is the set. Compare the customers in the sales system with the customers in the accounting system and fix the differences. Nothing happened, so there is no event.

There are two lists, a join and a set of corrections, run on a schedule. Built as a flow, it becomes a thousand separate runs, each looking up one record, the long ones timing out, and the two systems left half reconciled with no record of where the work stopped. A reconciliation needs a position it can resume from, a log of what it changed and a report at the end. That is a program, and a program is code. The second shape is the unit. Create the order, reserve the stock and raise the invoice, all of which must succeed together or not at all.

A flow runs its steps in order and stops at the first failure. If the stock reservation fails, you have an order with no reservation, which to the warehouse looks like an order it can ship. The platform has no way to undo step one because step two failed. Code does, and when a half-finished state costs money, the undo is the whole value. The third shape is the decision. Choose the carrier for this load, the supplier for this purchase, the next step for this ticket, using history, limits and prices.

A flow can branch on a field. It cannot weigh a situation. When a connection has to decide and not simply copy, it needs a written specification, and it is code or an agent with limits written down. Here is how to sort. Take your list of connections and add one column: shape. For each one, ask whether it is triggered by a single event and acts on a single 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 first group: does any flow depend on another having run first? A flow that raises the invoice from the deal depends on the flow that created the customer from the account. If the second runs first, the invoice has no customer. Order the triggers on purpose, or move the dependent pair into one coded connection. The sorted list is usually lopsided, something like fifteen flows and four coded connections, and 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.

Whatever the tool, every connection needs the same monitoring, and this is where a platform-only company is weakest. A flow that fails sends an email to the person who built it, who may have left. A coded connection writes to wherever its developer pointed it. Neither tells the business whether its connections are healthy. Give every connection, flow or code, one place to report: it ran, how many records, how many failed, which ones. Put the summary on one page, and name the person who reads it every week. A connection nobody watches is a connection that is already broken, and the business finds out from a customer.

To sum up. Use Zoho Flow for the connections that are one event acting on one record, without apology and without a developer. Use code for the three shapes it is not built for: sets, units and decisions. Do the sorting before the first connection is built, because a reconciliation that starts life as a flow is hard to unbuild. We are CodeStringers, a Zoho authorised consulting partner. A no-risk discovery sorts your connection list by shape, tells you which few need code, and you pay only if you go ahead.

The full article is linked below.