All resources
Perspective

Stop rebuilding the same integration

Quin Eddy CEO
Cover illustration for Stop rebuilding the same integration

Every enterprise I talk to has the same integration standing in more than one place. Same source, same destination, same shape, built two or three times because two or three teams needed it and there was never a way to move the first one. Nobody planned that. It is what happens when an integration is something you build rather than something you keep.

This release lets you save a working workflow as a template and stand it up anywhere: another workspace, another environment, another tenant.

A file you can keep

The time saved on the second build is real, but it is not the part I care about most. What matters is that the template is a standalone file.

That file is an independent artifact. You can hand it to another team, keep one for each solution you have standardized on, and track those as independent versions using whatever you already use for files.

Let me be precise about what that is and is not. There is no template library inside the product and no lifecycle managing these for you. This is not version control. It is a file, and that is exactly what makes it yours to keep, to copy, and to move.

What the file buys you is that the structure stops being re-derived. Applying a template involves no prompt and consumes no tokens, so what comes out is what went in, every time, across every dataset and every combination.

That determinism is what makes the goal enforceable. Every integration has a goal: the outcome dataset, the exact shape the receiving system needs in order to do its job. When the thing producing that shape is a fixed file rather than a fresh derivation, the goal is guaranteed rather than hoped for. The question stops being “did this run match the last one” and becomes “is this template right”, asked once.

At enterprise scale that is the difference between a dozen integrations you trust and a dozen you re-verify.

The columns that were never there

The second piece is quieter, and I think it matters just as much.

Real harmonization means pulling from systems that do not agree with one another. One source returns a column another has never heard of. A smaller entity has no rows for a segment it does not use, so its export arrives narrower than its larger sibling’s. The receiving system still expects the full set, and a shortfall anywhere breaks the load.

The new Pad Columns transformation handles that directly. You declare the columns the output has to carry, and they are there whether or not the source supplied them. Because a template captures every transformation in its pipelines, that guarantee travels with the file rather than being rebuilt alongside it.

That is what separates harmonizing twenty systems from harmonizing two. You stop negotiating with each source about what it happens to return, and you start holding every source to the shape you actually need.

Build it once. Keep the file. Run it everywhere.

More on the platform on the platform page.

Want this for your team?

Get started in minutes, or talk to us about your stack.