Resources · Integration patterns
ERP, CRM and commerce data synchronisation
One clearly named master system for each type of data, identifier mapping and safe, repeatable synchronisation.
Integration status: Future
Future: the product defines interfaces (CommercePlatform, CRMConnector) but no adapter for a specific system.
Description
For every object (customer, item, order, stock) a system of record is defined. Changes move by events or periodically, with a mapping table and a mismatch report.
Prerequisites
- A data model and a source of truth.
- APIs or events from the systems.
- A mapping table.
When to use it
- The same data in several systems.
- Manual transfer causes errors.
- Changes must be traceable.
When not to use it
- No agreement on the source of truth.
- Systems have no APIs.
- A one-off transfer — a migration is better.
Reference diagram
An illustration of the components and the flow — not a running system.
01Systems
- ERP
- CRM
- Shop
02Synchronisation
- Identifier mapping
- Conflict rules
- Idempotency
03Control
- Mismatch report
- Change log
The diagram as a list
| Stage | Components |
|---|---|
| Systems | ERP, CRM, Shop |
| Synchronisation | Identifier mapping, Conflict rules, Idempotency |
| Control | Mismatch report, Change log |
Security controls
- Separate read and write keys.
- Writes initiated by AI go through approval.
- No payment data in the synchronisation.
Observability
- Objects synchronised.
- Mismatches by type.
- Synchronisation delay.
Failure modes
| Failure | Mitigation |
|---|---|
| Duplicate write | Idempotency keys. |
| Conflicting changes | Rules by source of truth. |
| Silent drift | A daily difference report. |