Home/Data synchronization

04 / Data synchronization

Synchronize data.
Control conflicts.

Synchronize data with defined responsibilities and predictable updates. We define intervals, detect changes and account for conflicts, deletions and missed transfers.

Change detectionUpsertsConflict rules
INTEGRATION DIAGRAM / EXAMPLEDELTA / CONFLICT / UPSERT
SYSTEM A / ERP

AT-1042

version: 18
status: "active"
SYSTEM B / CRM

AT-1042

version: 19
status: "paused"
Δ STATUS / CONFLICT DETECTED
Field rule: the ERP owns “status.”

Both systems have changed the field. Agreed field ownership determines the outcome; a higher version alone is not sufficient.

UPSERT / SHARED ID
RECONCILED STATE

status: "active"

ERPAT-1042CRM

A change is detected. A conflict is resolved. A state is reconciled.

Starting point

Two editable records need clear rules.

When customer or product data is changed in two places, ownership of each field needs to be defined. Handling late, duplicate or out-of-order changes is equally important.

Applications

Which systems own which data?

Reconcile customers and contacts

Keep shared IDs and selected fields up to date between ERP and CRM. Each system's responsibilities remain defined.

Transfer products and inventory

Send relevant product and availability changes to shops, portals or marketplaces at an agreed interval.

Scheduled or event-driven

Use webhooks, change markers or scheduled polling to match the available interfaces and operational requirements.

Project scope

Delta.
Conflict. Acknowledgment.

Scope depends on your systems and the desired outcome. We agree on these points with you.

Real-time processing needs a measurable target.

Event-driven deliveries can also arrive late or fail. Systems using scheduled polling have different constraints. We agree on a measurable freshness target based on the available interfaces.

  • Field ownership and rules for one-way or bidirectional changes
  • Stable ID mappings and an agreed deletion strategy
  • Change detection and appropriate update intervals
  • Conflict handling and protection against update loops
  • Recovery and data reconciliation after interruptions
  • Monitoring for delays, invalid records and discrepancies

Service scope and responsibilities are agreed for each project. Our approach: acceptance and operations

Technical questions

Data freshness and field ownership.

Is synchronization in both directions possible?
Yes, with clear field ownership, conflict resolution and loop prevention. A one-way data flow is often easier to operate. The business process determines whether bidirectional changes are needed.
What happens to deleted records?
Deletions need an agreed rule: propagate the deletion, mark the record inactive or retain it for another purpose. A missing record is not automatically treated as a deletion request.
How often can data be synchronized?
The interval depends on API quotas, change detection, data volume and permitted system load. Options include webhooks, scheduled polling and regular full reconciliations.
How does the connection resume after an outage?
It needs a known recovery point or a fresh data comparison. Checkpoints, reprocessing and reconciliation ensure missed changes are detected.

Your next connection

What should your systems
achieve together?

You bring the requirements. We clarify the connections.

Discuss your project

Practical integration challenges

Technical topics in this area.

Data processes

Synchronize data between systems

A customer is updated in the CRM and in the ERP. Which version is authoritative? We design synchronization around business ownership and stable identities so that recurring transfers do not create silent data conflicts.

Data processes

Synchronize orders & status updates

The shop reports payment, the ERP has no order yet and shipping already has a tracking number. We connect these steps with defined states, unique order references and planned recovery.