It is the third week of the quarter. Finance is closing the books, and the pipeline number in your ERP does not match the one in your CRM. Not by much: a few hundred records, a couple of percent.
Nobody deployed anything. No alert fired. Every integration run in the last 30 days shows green.
This is what a healthy bidirectional sync looks like after eighteen months in production. It did not break. It drifted. Drift is the failure mode nobody puts a line item against, because when the budget gets approved, nobody is thinking past the connector.
What got approved is not what got built
The line item said “connect Salesforce to NetSuite.” The vendor demo took eleven minutes: pick the object, map the fields, turn it on.
That part really is that fast. The connector is just the smallest part of what you end up operating. The rest goes to four things that never appear in a scoping document:
- Deciding which system wins when both edit the same record
- Stopping the two systems from writing to each other in a loop
- Getting back to a correct state after something goes down
- Proving, on any given Tuesday, that both systems still agree
None of these are edge cases. They are the steady state, and each is a decision your team will make by accident if it does not make it on purpose.
Cost one: you shipped a data-loss policy and called it a default
Timestamps are not a tie-breaker
When both systems edit the same record between syncs, something decides who wins. Almost every default is last-write-wins by timestamp, a policy that silently discards one of two legitimate inputs. Nobody signed off on it, and it fails in specific ways:
- Clocks disagree. Batch jobs stamp records at commit time, not edit time, so a 09:02 change can carry a later timestamp than a 09:40 one.
- Ownership is per field, not per object. Sales owns the account name, finance owns billing terms, support owns health status. One object-level rule makes all three lose to whoever wrote last.
- Deletes are not writes. A delete on one side and an update on the other is beyond a timestamp rule, which is how records come back from the dead.
The fix is not a better algorithm. It is a field-ownership matrix, agreed with the business before anything is mapped. That is a week of meetings, and the cheapest week of the project.
Cost two: the loop, and the schema you now owe it
A writes to B. B’s change feed fires and writes back to A. A’s feed fires. You have built a machine that generates infinite work from one phone-number update.
The schema debt this creates
Everyone breaks the loop the same way: filter out writes by the integration user, or stamp a sync_source flag. Both work, and both leave integration-specific schema in production. A service account whose permissions cannot be tightened. A custom field every report has to ignore. That surface area outlives whichever platform you picked.
Duplicates are the contract, not the bug
Every iPaaS platform and change feed you evaluate delivers at-least-once, not exactly-once. Retries are how they survive timeouts, so duplicate writes are the deal. Salesforce’s own Pub/Sub API documentation notes that replay IDs are not guaranteed unique during maintenance such as an org migration, and tells subscribers to deduplicate on event ID instead. Deduplication needs an idempotency key the target system usually has nowhere to store. So you add another custom field.
Ask vendors not whether they handle loops, but what they require you to put into your systems of record so that they can.
Cost three: replay, and the blast radius you did not measure
Something will go down: a vendor outage, an expired OAuth token, another team’s Friday schema change. When it comes back, can you re-push 400,000 records without causing a second incident?
Your governance budget is smaller than you think
A Salesforce Enterprise Edition org gets 100,000 API calls per 24 hours plus 1,000 per user license. A 50-seat org has 150,000 calls a day for everything: the integration, BI extracts, every other connected vendor. Long-running concurrent requests are capped at 25 in production, so parallelising a backfill is how you take the org down for everyone.
NetSuite is often tighter. It governs concurrency per account rather than per integration, pooled across SOAP and RESTlet calls, so your backfill competes with every other integration in the account.
Catch-up also expires. Salesforce keeps platform and change events for 72 hours. Past that, you are not replaying, you are reconciling from scratch.
Writes trigger things
Every replayed record lands in a system with its own workflows, assignment rules and lifecycle emails. A replay is thousands of simultaneous business events. That is the mechanism behind every “we accidentally emailed 40,000 customers” story, and the root cause is always a replay path nobody designed. You need:
- A rate-aware replay that can run throttled over hours
- A way to suppress downstream automation during backfill
- The ability to replay one record, one object or one time window, not all or nothing
Cost four: you cannot claim it works if you cannot prove it
Green means it ran, not that it agrees
Back to the opening. Every run was green. Monitoring answers two different questions, and usually only the first:
- Did the pipeline run? Status, errors, latency. Every platform gives you this.
- Do both systems hold the same values? Record counts, field-level comparison, a drift number on a dashboard. Almost nobody builds this.
A reconciliation job does not demo and nobody asks for it, so it gets cut in scoping. Meanwhile drift accumulates from everything above: a conflict resolved wrong, a half-applied duplicate, a record missed during an outage, a validation rule that silently rejected a write. A handful a month becomes the gap finance is staring at.
If you take one budget line from this piece, make it a scheduled reconciliation job with an alert threshold.
Most of your bidirectional requirements are not bidirectional
This is the part that saves money. “Salesforce and NetSuite need to stay in sync” almost never describes genuine shared ownership. It describes two one-way flows on different fields.
Work it field by field
- Account name, owner, opportunity stage: Salesforce owns it, NetSuite reads.
- Invoice status, payment terms, credit hold: NetSuite owns it, Salesforce reads.
- Fields both sides genuinely need to write: usually a handful, sometimes none.
Make that split and everything above shrinks. Conflict policy applies only to the shared fields. Loops get simpler because flows are directional by design. Reconciliation becomes a one-way check against a known authority. The shared fields still deserve explicit rules, an audit trail and a human escalation path, but that is a small, well-defined problem.
The cheapest architectural decision here is the least technical one: assign an owner to every field before anyone opens the integration tool.
The platform question is an operating-model question
Most iPaaS evaluations become feature matrices. Every serious platform can move a record. What separates them is who maintains it at 2am, and whether those people write code.
Four options, and the org each one assumes
- API-led platforms (MuleSoft and peers). Right when integration is a product surface with governance and reuse needs across many systems, and you have a platform team to run it. Without that team, you are buying a capability you cannot operate.
- Recipe-based iPaaS (Workato and similar). Assumes maintainers sit closer to the business. You get faster time to value and a shorter maintenance tail, in exchange for the platform’s opinions on error handling and state. For a mid-market org with a small backend team, usually the right trade.
- Build it yourself. Sometimes right for two systems with unusual requirements. The trap is pricing the connector and not the scaffolding, which is where the years go.
- Platform plus implementation partner. The option most build-versus-buy framings skip: the platform for the runtime, the partner for the operating model. A good Workato integration service provider earns its fee on the four costs above, not the connector build. If nobody on your team has run a sync through two years of schema drift, it is usually the cheapest way to buy that experience.
None of these is universally right. What is universally wrong is choosing on connector count and discovering the operating model later.
Four questions before you sign anything
- Which system owns which field? If the answer is at object level, the work is not done.
- What happens when both sides change the same field between syncs? “The platform handles it” means last-write-wins, unapproved.
- What is the replay plan? How do you re-push a day of records without exhausting API quota or firing every downstream automation?
- How will you know the systems have drifted, and who gets paged? No scheduled comparison means finance tells you.
If your team can answer all four, the platform choice is a preference. If not, no vendor demo will surface that for you. The integration gets built either way. The only question is whether these costs land in the project plan or in next year’s unexplained variance.
