Flow Builder at the product's edge: data transformations with ZIS

Some requests a support team can’t solve at all, because a different provider owns the answer. One case like that kept landing in our chat: the customer needed a piece of information we were only a pass-through for. For the team it meant effort with nothing to show for it; for the customer, waiting for an answer that came down to “For that, you’ll need to contact …”. The obvious move: automate the case so the customer pulls the information themselves, end-to-end inside the bot.

The limit: API calls yes, transformation no

The plan sounded simple. Flow Builder, the classic Zendesk bot, can make API calls mid-conversation and show response fields. Our case needed more: pull data from a first system (personal data, name and more), reshape that data, and use the result to call a second system. Only that second response held what the customer needed.

That’s the product’s limit: Flow Builder calls APIs and passes fields through, but it can’t transform anything. No reworking values, no assembling payloads from multiple sources, no logic in between.

The detour: an inbound webhook into ZIS

The solution ran through Zendesk Integration Services (ZIS), the integration layer that ships with the Suite but almost nobody touches by choice. The architecture:

Customer in chat
   │
   ▼
Flow Builder ── API call ──► ZIS inbound webhook
                                 │
                                 ├─ Call system A (fetch data)
                                 ├─ Transform (build payload for system B)
                                 ├─ Call system B (the real answer)
                                 └─ Cache the result
   ┌─────────────────────────────┘
   ▼
Flow Builder reads the result and replies –
solves the request or cleanly points to the right place

The bot sends the data to the inbound webhook flow, ZIS runs the calls and the reshaping and caches everything that matters. Once it’s done, the bot reads that data and closes out the case: either the request is solved, or the customer gets the information that lands them in the right place with the provider who owns it. That second outcome is a real solution too: deflection with substance instead of “nothing we can do here”.

What the detour cost

ZIS has one design flaw that hurts day to day: no user interface. Flows are built and deployed as JSON definitions. Every change is hand-coded, every debugging pass flying blind through the logs instead of a glance at a visual editor. What passes for a sporting challenge on the first build gets expensive in maintenance: whoever has to adjust the flow six months later needs expert knowledge again, not five minutes in the Admin Center.

In exchange, the detour had one solid upside: ZIS adds no extra cost. So the math was a one-time expert effort against a permanently free, fully automated case. It added up. The case ran, the customer got their information without routing through us, the team got its time back.

The verdict

Would I build it that way again? No. What we had to hand-assemble with ZIS, Zendesk now ships as a product. Action Flows make data processing in the bot context accessible through a real interface, intuitive enough that you no longer need an integration specialist for it. They come with a generous usage limit instead of the free label ZIS wore, but the difference in upkeep is worth the price.

What the new path looks like, where its limits are, and which old ZIS constructs you’d retire today is in the blueprint Action Flows: what replaces the ZIS detour today.