Your Transaction Lives in Your System. Why Doesn't Your Workflow?
Every core business transaction — the invoice, the purchase order, the hire — lives in your system. The approval that authorizes it shouldn't live somewhere else. Here's why the enterprise world is finally realizing this.
Think about what happens when a purchase order is created in your ERP.
The record is yours. It lives in your database, on your infrastructure, under your governance. Your finance team can query it. Your auditors can inspect it. Your developers can trace every field, every timestamp, every state change. If something goes wrong, you know exactly where to look — because the data is in your house.
Now think about what happens next. That purchase order needs an approval. And for that, you send it somewhere else entirely. To a vendor’s cloud. Into a shared tenancy you don’t control. Through an API that has rate limits you didn’t set, processed by logic you can’t inspect, stored in a schema you don’t own.
The transaction stayed home. The workflow moved out.
Nobody made a deliberate decision to split these two things. It happened gradually — one SaaS subscription at a time, one convenient demo at a time — until the pattern was so established that it stopped feeling strange. Of course your approvals run on a separate platform. That’s just how it’s done.
But ask the question plainly: if your core business transaction can live in your own system, why can’t the workflow that authorizes it live there too?
There is no good answer. There is only inertia.
The separation has always been artificial
An approval workflow is not a separate process from the transaction it governs. It is part of the same event.
The purchase order and its approval chain are one thing. The invoice and the sign-off that releases payment are one thing. The hiring request and the multi-level authorization that converts it into a contract are one thing. The transaction does not exist independently of the decision that authorized it — and the decision does not exist independently of the transaction it touches.
When you put the transaction in one system and the workflow in another, you are splitting a single event across two owners. And every problem that follows — the integration overhead, the data synchronization lag, the audit complexity, the vendor dependency — flows directly from that original split.
Your ERP knows the purchase order amount, the vendor, the cost centre, the budget remaining. Your approval platform needs that same information to route the request correctly. So you build an integration. The integration needs to stay current as your data model evolves. The integration has its own failure modes. The integration adds latency to every approval event.
You built all of that complexity to solve a problem you created by separating two things that should have stayed together.
What customer ownership actually means
There is a phrase that gets used loosely in enterprise software conversations: customer-owned systems. It sounds like it means “build everything yourself.” It doesn’t.
It means the systems that encode your business logic — the rules, the conditions, the decision criteria that define how your organization operates — run in infrastructure you govern. Not infrastructure you built from scratch. Infrastructure you control.
In practice for approval workflows, this looks like:
Your approval rules live in your repositories — version-controlled, testable, readable by your team. When a rule changes, you change it. You do not raise a ticket and wait for a roadmap.
Your orchestration layer runs in your environment — a container in your cluster, a service in your stack. It connects to your systems because it is one of your systems. It reads the transaction data it needs directly, without an integration that needs to be maintained.
Your approval records write back to your database — the same database that holds the transaction they govern. The purchase order and its approval history live together, queryable together, auditable together. No cross-system reconciliation. No proprietary export format. No asking a vendor for your own data.
The transaction and the workflow finally live in the same house.
Three forces that make this the right moment
This is not a new idea. Enterprises have wanted this for years. What is new is that the practical barriers have fallen.
Regulatory pressure has made data location a board-level question. GDPR, financial services regulations, healthcare compliance frameworks — all of them require organizations to know where their data is, how decisions were made, and who had access to what. When your approval workflow runs on a vendor’s shared cloud, answering those questions requires the vendor’s cooperation. When it runs in your environment, you answer them yourself. The compliance team stops waiting on vendor support tickets.
Infrastructure has matured to the point where this is routine. Running a sophisticated orchestration layer in your own environment used to require a dedicated platform engineering team. Today it is a container, a configuration file, and a deployment pipeline your team already operates. The operational burden that once made vendor-hosted platforms attractive has largely disappeared. You are not choosing between capability and control anymore. You can have both.
The real cost of SaaS sprawl is now visible. After a decade of accumulating subscriptions, enterprises are doing the arithmetic. The license fees are one line on the invoice. The integration costs, the migration costs, the developer time spent learning proprietary systems, the business disruption every time a vendor changes their API — these do not appear on the invoice. When you add them up over a five-year horizon, ownership is almost always cheaper. And it compounds: every year you own your workflow logic is a year of institutional knowledge that stays inside your organization instead of being encoded in someone else’s platform.
The approval that should never have left
Return to the purchase order from the beginning of this post.
Somewhere in your organization right now, there is a system — your ERP, your procurement platform, your financial system — that knows everything relevant about that transaction. The amount. The vendor. The budget. The cost centre. The requestor. The approval history of every similar transaction in the past three years.
All of that context exists in your system. Your approval workflow needs all of that context to make a good decision. And yet, by routing the approval through a separate vendor platform, you are forcing that context to travel — across an API, into a foreign schema, processed by logic you cannot see — before it can do its job.
The workflow does not need to travel. The transaction context does not need to be replicated. The approval record does not need to live somewhere else and sync back.
The entire event — transaction, workflow, decision, audit record — can happen in one place. Your place. With your rules, your data, your governance, your visibility.
When the transaction lives in your system, the workflow that authorizes it should live there too. Not as a philosophical preference. As an architectural decision that eliminates an entire class of problems — integration failures, vendor downtime, data sovereignty gaps, audit complexity, lock-in risk — before they can occur.
What Zetlane is built to do
Zetlane is an orchestration layer, not a platform. The distinction matters.
A platform asks you to bring your process to it. An orchestration layer comes to your process — running in your environment, connecting to your systems, reading and writing to your data stores, operating under your governance.
We handle the complexity of multi-level approval chains, escalation logic, delegation, real-time event routing, and audit trail generation. But all of it runs inside your infrastructure. Your approval data never crosses into our systems. There is nothing to export, nothing to migrate, no proprietary format to decode.
The transaction stays in your system. The workflow stays in your system. The orchestration is the only thing we provide — and it lives in your house too.
That is what it means to own your workflow.
Zetlane orchestrates enterprise approval workflows entirely within your own infrastructure. If you’re ready to stop splitting your transactions from the workflows that govern them, we’d like to talk.
Want to see Zetlane in action?
Get in touch →