Why Integration Projects Should Start with Business Processes — not APIs
Here's how most integration projects begin: someone opens two API documentation sites side by side and starts mapping fields. Account maps to Customer. Opportunity maps to Sales Order. Six weeks later the data flows perfectly — and the business is somehow no better off. The invoices still go out late. The handoffs still stall. The process didn't change; it just got faster plumbing.
The problem isn't the mapping. It's the starting point. APIs describe what systems can exchange. Only the business process tells you what should happen, when, and what to do when it doesn't.
What API-First Projects Get Wrong
They sync everything, needed or not
Field-mapping sessions default to "map it all," creating fragile, noisy integrations where 80% of the synced data serves no decision and every schema change breaks something.
They automate the current mess
If today's process includes three approval emails and a spreadsheet, an API-first project faithfully reproduces all of it — just faster. You've paved the cow path.
They ignore exceptions
APIs define the happy path. But the business lives in the exceptions: the partial payment, the credit hold, the order change after invoicing. Unplanned exceptions become silent failures.
They have no success metric
"The data syncs" is a technical outcome. Without a process definition, nobody agreed what business result — faster invoicing? lower DSO? — the project exists to move.
The Process-First Method
- 1. What's the trigger? "Opportunity marked closed-won." "Payment received." "Subscription renewal due in 30 days." Every flow starts with a business event, not an endpoint.
- 2. What's the desired end state? "Customer invoiced within five minutes, payment collected, CRM updated, rep notified." A sentence a CFO can verify.
- 3. Who decides what, along the way? Which steps are automatic, which need approval, and above what thresholds? This is where governance gets designed in — not bolted on.
- 4. What are the exceptions, and who owns them? List the ten ways the flow fails and name a human queue for each. An integration without an exception path is an outage waiting for volume.
- 5. What number should move? Days to invoice, DSO, error rate, hours of manual work. Pick it before building, measure it after.
Only after those five answers exist does field mapping begin — and it gets dramatically easier, because now you're mapping the twelve fields the process actually needs instead of four hundred that it doesn't.
"APIs tell you what's possible. Processes tell you what's valuable. Integration projects fail when they confuse the two."
Why This Is How InterWeave Works
This is why InterWeave engagements start with a process workshop, not a connector list. The platform's SmartFlows are built around business events — quote-to-cash, order-to-cash, renewals, collections — with approval steps and exception queues as first-class citizens. The 200+ pre-built connectors make the API layer a solved problem, which is exactly what frees the project to focus on the layer that isn't: how your business actually works, and how it should.
The result reverses the usual failure pattern. Instead of a technically perfect sync nobody notices, you get a business outcome everyone does — invoices in minutes, exceptions in a queue with an owner, and a number on the CFO's dashboard moving the right direction.
Before your next integration kickoff, ban API docs from the first meeting. If the team can't describe the process in business sentences, they're not ready to map fields.