While accounting was updating the current account address, the field team changed the phone number on the same card, and the sync is trying to overwrite both. A record written by both sides at the same time is the most frustrating moment of integration.
Conflict is inevitable; the important thing is that the rule is written in advance and resolved visibly. In this article, we explained the priority, last-writer-wins, and manual queue approaches.
EQLEM is a solution platform; while working alongside your existing ERP system, it reduces conflict through field ownership rather than eliminating it.
Table of Contents
What is a conflict?
A conflict occurs when the same record is changed with different values in two systems, and the sync doesn't know which one to write. This results in silent overwriting or waiting in a queue.
A conflict is not always an error; the business reality may have changed on both sides. The real problem is that the rule is undefined.
Field-level conflict and record-level conflict must be separated. While the phone number changes, the address may remain the same.
A conflict cannot be resolved without a timestamp; it is not known which change is newer. Clock synchronization is also a must.
We laid out the planning in the ERP sync plan article.
Why does it occur?
Bi-directional open fields are the most common cause; if both sides can write, conflict is statistically inevitable. Restricting write access reduces conflicts.
Delayed sync also produces it; the old value overwrites the new value. Frequency and order become important.
If manual corrections are made outside of integration, the system magnifies the discrepancy. Single-channel discipline is required.
Mapping errors lead to writing to the wrong record, which looks like a false conflict. Verify the mapping first.
If the habit of double data entry continues, conflicts increase; the end of double entry supports this place.
Field ownership
The safest method is to allow a single system to write to each field. The other side views the field as read-only.
Such division is common, like tax ID in the existing ERP and delivery note on the platform. It is split according to business needs.
The ownership matrix must be kept in writing and up to date; when a new field is added, the matrix is updated. Forgotten fields generate conflicts.
If read-only fields are displayed in gray in the user interface, incorrect updates decrease. Training alone is not enough.
Ownership violation attempts are logged; repeated violations indicate a process issue. Without logs, the need for training is not visible.
Priority rules
System priority can be defined; for example, in financial fields, the existing ERP always wins. This rule is simple and understandable.
Role priority is also possible; an approved accounting user overwrites a field update. The authorization model must be clear.
Priority can change according to the document type; an invoice record overrides an order note. A type matrix is required.
The priority rule can also be explained to the customer; transparency shortens debates. Hidden rules destroy trust.
When rules change, past conflicts should not be replayed; it only applies forward. Retrospective rewriting can cause data loss.
Last writer wins
The value with the newer timestamp wins; implementation is simple but risky. A system with an incorrect clock produces a false winner.
This method works in low-criticality fields, such as phone and notes. It is not suitable for taxes and balances.
Aligning clocks with NTP is mandatory; otherwise, the illusion of the last writer occurs. Infrastructure interferes here.
The winning value must be stored in the log along with its old value. Traceability is ensured during audits.
In frequently conflicting fields, ownership should be preferred instead of last writer. If statistics are high, change the rule, do not overwrite more often.
Manual resolution queue
In critical areas, human judgment is preferred over automatic overwriting. The queue shows two values side by side.
A responsible role must be assigned; an open queue becomes no one's job. A queue without an SLA swells.
If a decision rationale is made mandatory, recurring errors are learned. Blank approvals leave people untrained.
Queue age must be monitored; records older than one day should trigger an alarm. Old conflicts ruin the work.
We covered the error tracking setup in the integration errors article.
Prevention methods
Restricting write access is the most effective prevention; reading is cheap, writing is expensive. Do not open every field.
Using a modification key or version number catches conflicts early. It refuses to overwrite an older version.
Add ownership rules to user training; interface barriers are not enough. Habits must change too.
We suggested keeping the flow direction narrow in the Logo and Mikro guides; the same principle applies here.
Measure the number of conflicts during the pilot period; if high, redraw ownership. A pilot without metrics hides the real risk.
Monitoring and alarming
The number of conflicts should be visible on the daily dashboard; a sudden spike indicates a mapping or training issue. Invisible metrics cannot be managed.
Field-based heatmaps show which field is problematic. Tighten ownership there.
Alarms should only go to the relevant integration owner. Notification management cuts out the noise.
Monthly summaries go to management; operational details stay with the team. The same report should not go to everyone.
On-prem connection drops may also look like conflicts; check the connection first.
Common scenarios
In current address conflicts, the financial address must be separated in the ERP and the shipping address on the platform. A single address field is not enough.
If product descriptions are edited on both sides, the product card gets corrupted; the description is tied to a single owner. Codes are never written twice.
Order lines originate on the platform, and invoice lines in the ERP; write-backs are kept limited. Document conflicts are expensive.
Logo and Micro software contains direction examples.
The balance field must never be written twice; a read-only copy is sufficient.
Points to consider
Do not discover the rule in production; the conflict policy is part of the plan. Rules written later cause data loss.
Do not make every field 'last writer wins'; critical financial fields will be damaged. Field separation is mandatory.
Do not replace ERP with EQLEM; ownership is consciously divided between the existing system and the platform.
Do not leave the manual queue unowned; accumulated decisions will lock up operations.
Do not neglect clock synchronization; the wrong timestamp produces the wrong winner.
Frequently asked questions
Is it possible to completely prevent conflict?
It is hard to prevent completely; it is largely reduced through field ownership. The rest is managed by rules and queues.
Can 'last writer wins' be used everywhere?
It should not be; it should be limited to low-criticality fields. Ownership or manual decision is preferred in financial fields.
Does EQLEM replace the existing ERP?
No, it does not; it works alongside it as a solution platform and supports data consistency with synchronization rules.
How long should the queue take to clear?
Critical records on the same day; others within one business day. Longer durations should trigger an alarm.
Conflict stems from undefined double-writing, while the solution comes from ownership and clear rules. Silent overwriting is the most expensive way.
Assign fields to a single owner and use a manual queue for critical ones. Do not spread 'last writer wins' everywhere.
Monitor conflict metrics daily; a sudden spike indicates a process or mapping issue. Send the alarm to the right person.
Align clocks and log decisions; it must be traceable during audits.
Write the conflict policy during the planning phase; discovering it in production causes data loss.
By consulting with the EQLEM team, you can clarify your synchronization conflict rules.