Integrations
Keeping two systems in sync
Which one wins when both hold the same value and they disagree.
As soon as two systems store the same value, at some point they stop matching. That is not an integration fault: it always happens. What decides whether it hurts is having agreed beforehand which of the two owns each thing.
The rule: one owner per field
Not "the ERP wins" or "the platform wins", but field by field. Each value has one place where it is edited, and the other only copies it.
| Value | Usual owner | Why |
|---|---|---|
| Supplier tax details | Your ERP | It is where invoicing happens |
| Documentation status | The platform | It is where it arrives and gets approved |
| Contact for paperwork | The platform | It receives the notices and shows whether they bounce |
| Whether the supplier is active | Your ERP | It is a commercial decision, not a documentary one |
Important
Write that table before coding anything, even if it is four rows in a document. Integrations that become a problem do not fail technically: they fail because nobody agreed who owns what, and end up overwriting each other in a loop.
What prevents duplicates
Watch out
If your system creates a supplier whenever it cannot find one by name, you will end up with "Muñoz Engineering", "Muñoz Engineering Ltd" and "MUÑOZ ENGINEERING". Searching by identifier rather than name is what prevents it.
Worth knowing
Start by syncing one way only. Bidirectional is where loops appear, and it is rarely needed at the start.
›What if both change at once?
The field's owner wins. Which is why it has to be defined first.
›Can I sync only some suppliers?
Yes, and it is a good way to test.
›How do I spot they have drifted apart?
By comparing on the identifier occasionally. Without one, you cannot.
A real case
The situation
An integration creates duplicate suppliers whenever the name arrives with a different comma.
What you do
- Adds the tax identifier as the lookup key
- Searches on it before creating
What you get
Duplicates stop appearing and the 40 already there are merged without losing history.
The situation
The supplier record is edited here and in the ERP, and each system holds a different version.
What you do
- Decides which one is authoritative for each field
- The other system receives the change rather than editing it
What you get
There stop being two truths and nobody has to guess which one counts.
The situation
Both systems are edited at once and the last write wins silently.
What you do
- Locks editing where that field is not authoritative
What you get
The change is made in one place and propagates.
The situation
The sync goes down over a weekend and nobody notices until Tuesday.
What you do
- Sets an alert if activity stops arriving
What you get
The drift is caught in hours.
The situation
Everything is synchronised when only four fields were needed.
What you do
- Limits the sync to what is used
What you get
There is less to maintain and less to break.
The situation
A field changes format in the ERP and the sync starts failing.
What you do
- Validates the format before writing
- Returns the error to whoever generated it
What you get
The fault is fixed at source rather than carried along.
This article answers
- sync with erp duplicate data
- which system owns a field
- data does not match between systems
- avoid duplicates when integrating