Data processes / 07
Two systems. Clear rules for the same record.
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.
The starting point
Bidirectional does not mean every field flows both ways.
The CRM owns contact details; the ERP owns billing addresses and payment terms. Both store the same customer under their own IDs. A blanket “latest timestamp wins” rule can replace an approved ERP address with older CRM content.
We examine fields and processes individually. Stable IDs, change markers and deletion information are essential. Without reliable delta access, a controlled full reconciliation is often more realistic than apparent real-time operation.
What DataSource delivers
Detect changes. Resolve conflicts.
Identity
Map local IDs and detect business duplicates. Define separate procedures for new, merged and deleted records.
Directions
Define ownership per field. Add versions or origins to changes where supported by the systems to limit feedback loops.
Reconciliation
Process deltas, persist acknowledged progress and schedule regular comparisons as a corrective measure. Resolve conflicts with the responsible team.
Kunde 004218
ERP → CRM: billingAddress, paymentTerms
CRM → ERP: contactName, contactPhone
Version passt → definierte Felder aktualisieren
Version weicht ab → erneut lesen / Konflikt klären
Datensatz gelöscht → vereinbarte Löschregel anwendenTechnical scenario / Illustrative example
Distribute an address change selectively.
Illustrative state plan. The ERP owns the billing address, while the CRM owns the contact. A version conflict is made visible rather than blindly overwriting the entire customer record.
Example data and proposed rules. The actual interfaces and business rules are assessed for your project.
Error handling, security and operations
Conflict, deletion and progress.
Deletions
Absence from an incomplete response is not a deletion event. Tombstones, archival rules or a confirmed complete dataset need to provide the meaning.
Interruptions
After an outage, resume from the last acknowledged state. If change data has expired, perform a defined reconciliation from scratch.
Data freshness
Agree on time windows and acceptable delay. Real-time processing cannot be reliably promised without a suitable source, target capacity and operational ownership.
Technical questions
Details that matter before implementation.
Delta · Reconciliation · Field ownership · Conflicts · Deletions
Can the same field be changed in both systems?
Yes, but it needs a conflict rule or approval process. A timestamp rule is appropriate only when its business effect and time basis are suitable.
Do webhooks prevent all missed updates?
No. Events can arrive again, late or out of order. Supplementary reconciliation may be useful depending on the provider.
How do we handle duplicates?
Clarify identity rules and existing data quality first. Uncertain matches require review rather than an automatic merge.
For technical clarification
Start with your actual workflow.
Describe systems, data objects, example IDs, desired directions and acceptable delay. Examples of conflicts and deletions are particularly valuable.
In our initial discussion, we clarify available access, data ownership and a narrowly scoped first data flow. We then agree on scope, responsibilities and commercial terms.
Anonymized examples are enough to get started. Please do not send passwords, tokens or personal data from production systems in your initial inquiry.
Related challenges
Your next connection in context.
ERP and CRM interfaces
Sales and accounting work with the same customer for different purposes. DataSource connects the supported interfaces and clarifies which data is transferred, and when, between prospect, customer and debtor records.
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.
Process webhooks reliably
An event arrives and needs to trigger an action in the next system. Duplicate delivery, delays or an unavailable target API turn this into an operational process. We develop that workflow with uniquely identified events and verifiable effects.