Business applications / Practical guide
ERP and CRM Data Ownership: Source of Truth, Idempotence and Exceptions
ERP and CRM integrations become fragile when every system believes it owns the same customer, order or status. A practical design assigns ownership by field and process, uses stable identities across boundaries and makes exceptions visible to the people who can resolve them.
Assign ownership by business object
“The CRM owns customers” is often too broad. One system may own prospect activity, another the legal account, another credit status and another the billing address used for a document. Build an ownership map at the field and process level. Name who can create, approve, update and retire each value.
Ownership also changes by lifecycle stage. A CRM may own a lead until qualification, while ERP becomes authoritative for the account and financial dimensions after an order is accepted. The integration should reflect that transition rather than allowing both systems to overwrite each other indefinitely.
| Object | Possible owner | Handoff to define |
|---|---|---|
| Prospect activity | CRM | When a qualified account is created |
| Legal account | ERP or master-data service | How CRM receives the stable account ID |
| Order | ERP or commerce platform | Which order status CRM may display |
| Service case | CRM or support platform | Which financial or delivery context is read-only |
Make identity stable across systems
Names and email addresses are useful for people but unreliable as integration keys. Create a stable cross-system identity with a clear authority, version and lifecycle. Keep the source identifier and destination identifier together, and document how a merge, split or duplicate is resolved.
The identity contract should state whether an operation creates, updates, links or only reads. It should also state how a missing reference is handled. A failed lookup should not quietly create a second customer because an integration did not find the first one.
- Use stable business and system identifiers
- Keep source and destination IDs linked
- Define merge and duplicate rules
- Distinguish create, update, link and read operations
- Never use display text as the only key
Make repeated messages safe
Messages can be delivered more than once because a sender times out, a queue retries or an operator replays a failed batch. Idempotence means that repeating the same business operation produces a controlled result rather than an unintended duplicate. The key must represent the business operation, not only the transport attempt.
For creates, store the idempotency key and the resulting destination reference. For updates, decide whether the operation is a patch, a versioned replacement or an event that can be applied only once. For deletes or status transitions, require an explicit business rule and an audit trail.
- Derive a stable operation identity
- Check whether the operation was already applied
- Return the prior result for a safe duplicate
- Record a conflict when payloads differ
- Allow an operator to reconcile the exception
Design exceptions for people
An integration exception is part of the operating model. A support person needs the business reference, company, field or rule that failed, the previous status and the safe next action. A raw stack trace or an entire customer payload is rarely enough and may expose sensitive data.
Separate transient failures from business failures. Rate limits, network timeouts and temporary service errors may be retried under a bounded policy. Invalid tax data, missing dimensions or a rejected status require correction or approval. The interface should make that difference obvious.
- Classify retryable and non-retryable failures
- Show business references before technical detail
- Mask sensitive values
- Keep correction and replay separate
- Record who resolved the exception
Keep access and company boundaries explicit
A system connection is not automatically allowed to read or write every record. Define the identity, role, legal entity, company scope and action list for each integration. In Finance & Operations, company context and entity keys are part of the request contract. In CRM, account teams and record ownership may further limit access.
Do not put client secrets or tokens in browser code, example payloads or public documentation. Use server-side credentials, allowlisted operations and auditable access. A data ownership map is incomplete if it does not say who may change the source of truth.
Prove ownership with end-to-end scenarios
Acceptance should follow a record through creation, update, duplicate delivery, correction and closure. Test ownership handoffs and verify that the receiving system displays the source status without becoming an accidental second master.
Include a scenario where one system is unavailable and another receives a later update. The expected result should identify whether the message is queued, rejected, reconciled or requires an operator. This is the difference between a data map and an operational integration.
- One system creates the record
- The other system receives the intended fields
- A duplicate is safe
- A conflict is visible
- The final owner can confirm the result
Primary sources
Sources and further reading.
These platform references support the technical guidance. Available features, versions and implementation requirements should be checked against your environment.