Which system is the source of truth when you sync tools?

Direct answer

When two systems both hold the same fact, such as a customer's email, a deal amount or an order status, one of them must be the system of record for that fact. It is the place where the value is created or edited and the place other systems copy from. The decision is made per field, not per system: your CRM may own contact details while your billing tool owns invoice status and your operations database owns delivery dates. Once each field has one owner and one direction of flow, conflicts become rare and explainable. Without it, values drift and people stop trusting either system.

This page is about data ownership. It is a different job from workflow exception and escalation design, which is about what people do when a process cannot proceed, and from AI automation failure handling, which is about technical retries.

Symptoms of no clear owner

The signs are recognisable once you look for them, and they usually appear as complaints about the data rather than about the integration.

• Someone corrects a phone number in one tool and it reverts overnight.
• The same customer appears with different spellings or addresses in two systems.
• Reports from two tools disagree and each team says theirs is right.
• A sync overwrites recent edits with older values.
• Nobody can say which tool to fix when a value is wrong.
• Staff keep a private spreadsheet 'because it is more accurate'.

The field ownership table

Build a table with one row per field that exists in more than one system. Columns are the field, the owning system, who may edit it and where, the systems that receive it, and any transformation on the way. Keep it to fields that actually matter to a process or report; a hundred rows nobody reads is worse than twenty that are enforced.

Choose the owner by asking where the fact is truest and where people naturally maintain it. A billing address belongs where invoices are issued. A sales stage belongs in the CRM where reps work. Consent or opt-out state belongs wherever it is captured and honoured first, and it deserves special care, since a wrong copy can cause real problems. If you are unsure how to treat such data, confirm with a suitable adviser rather than guessing.

Where a field is truly edited in two places, ask whether it is really two fields. A 'company name' used on invoices and a 'company name' used in casual sales conversation may legitimately differ. Splitting them removes the conflict instead of arbitrating it.

Direction of sync

One-way sync from the owner to the others is the simplest and safest pattern. Two-way sync is sometimes needed, but each field should still have a single owner at any moment; two-way then means each system owns different fields, not that both may edit the same one.

Prefer fewer, clearer flows. A hub design, where one system feeds several others, is easier to reason about than a mesh where every tool syncs with every other. When someone proposes two-way sync of everything, ask what would go wrong with one-way plus a link back to the source record.

Conflicts

Even with ownership, conflicts arise: someone edits a value in a receiving system, or two updates cross in time. Decide the rule in advance and make it visible. The usual options are that the owner always wins and the change in the receiving system is overwritten, that the latest edit wins, or that conflicts are held for a person to review. Owner-wins is the easiest to explain, but should be paired with making the receiving field read-only or clearly labelled, otherwise staff will edit it and be confused when it reverts.

Latest-edit-wins sounds fair but is fragile if clocks, time zones or batch delays differ. Use it only when you understand exactly how timestamps are set. For anything that affects money, contracts or customer commitments, hold conflicts for review.

IDs and matching

Sync depends on knowing that a record in one system is the same thing as a record in another. Do not match on names or free-text fields. Store each system's own record ID in the other system, and match on that. Email or a tax number can help create the first link, but once the link exists, the ID is the anchor, so that edits to the email do not create a duplicate.

Decide how the first match is made, what happens when there is no match, and what happens when there are several. Unmatched and multi-match cases are exceptions that need an owner, which is how this topic connects to preventing duplicate leads in a CRM. Plan deletion too: if a record is removed or merged in the owner, what should happen downstream?

Failure and replay

Syncs fail: a system is unavailable, a value is rejected, a batch is interrupted. Design so that a failed sync can be safely repeated without creating duplicates or reverting newer data. That means updates keyed by record ID and idempotent where possible, and a log of what was sent and when, so you can compare and re-send.

Keep a way to run a reconciliation: compare owner and receiver for the fields in your table and list the differences. You may run it rarely, but its existence turns a vague suspicion of drift into a concrete list. We do not claim any sync is real-time or lossless; how fresh values are depends on the systems involved and how the flow is built, and we state that in scope.

Documenting the map

The ownership table, the sync directions, the matching rules and the conflict policy should live in one short document that the people who maintain the systems can find. Include who owns the document. Update it when a field is added, a tool is replaced or a process changes. When you consider a custom API or a new integration, this document is also the brief: it tells the builder what must flow, in which direction, and what must never be overwritten.

How LATYNEX approaches this

Before building an integration we agree the field ownership table with you, because the build follows from it. One integration workflow across up to three systems can be scoped as the fixed-scope Automation Sprint (€1,690); more systems or complex conflict rules are custom scope. We confirm what each system's interface actually supports and do not assume ready-made connectors. Use the Automation Opportunity Finder to see whether your integration is a good first project, and see workflow automation and systems integration for the service.