What is a source of truth in a two-way integration?
Two systems can exchange data without both owning every field. Define who can change each fact before deciding which direction it moves.
A source of truth is the system your business treats as authoritative for a particular fact. In a two-way integration, that does not have to be the same system for every field. Sales may own a contact's relationship information while accounting owns payment status.
The useful question is therefore more specific than which app is the leader: who is allowed to change this fact, and what should the other systems do when it changes?
Two-way does not mean every field moves both ways
An integration can contain flows in both directions while each flow has a clear owner. That is often easier to reason about than letting either system overwrite the same information.
Dean Cabinetry's published story illustrates the split. A new customer is created in Acumatica when a Salesforce deal reaches the right stage, and sales orders, products and line items follow the same way. Payment links and payment information move back from Acumatica into Salesforce, where the client managers work.
The systems exchange data because they have different responsibilities in the same process.
This is different from a design where the latest update wins for every field. That approach may fit a specific case, but it needs explicit rules. A timestamp alone does not tell you which team was entitled to change the record.
Define ownership at the level people use it
Take an illustrative customer record shared by sales and finance. The record may contain an account owner, billing address, payment status and internal credit information. Those facts serve different decisions. Ask the responsible teams where each fact is maintained today. Then decide which edits should propagate and which should remain local. An internal sales note may not belong in accounting at all.
Write those decisions in language the teams can review. "Finance owns payment status" is understandable. "Bidirectional customer sync" leaves too much unresolved for a person who needs to sign off on the result.
Identify the record before moving its fields
Field ownership does not help if the systems disagree about which customer the record represents. Decide how records match and keep the identifiers needed to trace that match. Avoid relying on a company name alone when your data includes branches, similarly named customers or separate legal entities. If an existing match is uncertain, send it for review rather than creating a new customer automatically.
Your business also needs to decide what a duplicate means. Two contacts at one business are not necessarily duplicates. Two accounting accounts with similar names may represent different billing arrangements.
Decide what happens to competing edits
Consider a billing address updated in both systems before the next run. Which value should survive? Should one update be rejected, should the change wait for review or does a defined field owner settle the conflict? There is no responsible universal answer without knowing the process. The important work is agreeing on the behavior before the integration meets the conflict in production.
Include deletions and inactive records in that conversation. Removing a sales contact does not automatically mean finance should delete a customer with historical transactions. An inactive flag may be the appropriate downstream change instead.
Keep local fields local
Not every useful field needs to travel. A destination may hold notes, classifications or calculated values that belong only to its own work. Make those boundaries part of the mapping so a later update does not erase information someone legitimately maintains there. A record arriving successfully is not a good outcome if it overwrites the work another team owns.
Test ownership with competing examples
Use ordinary records and cases that challenge the rules. Include an existing customer with a new email and an address changed in both places. Add an inactive record and an uncertain match. Ask the business owner what should happen in each case before looking at the integration's output. That keeps the test from approving whatever the software happened to do.
Revisit the rules when ownership changes
A new accounting system, a new sales process or an acquisition can change which team owns a fact. The mapping should be reviewed alongside that business change. Write the new owner beside the field, not in a separate note nobody reads.
This is part of the work after launch. A flow can continue running successfully while carrying yesterday's ownership rules into today's process.
If both teams believe their system owns the customer record, bring them into the same requirements conversation before anyone builds the sync.