Designing a CRM–ERP customer lifecycle.
A premise-led architecture for a fictional global B2B company—from commercial intent to a legally valid, operationally recoverable customer.
Independently created. Contains no employer or client implementation detail, internal names or figures.
01Executive brief
The integration is not the architecture.
A global B2B company wants CRM to “create customers in ERP.” The phrase hides three different identities, two approval boundaries and a failure state that can interrupt revenue.
Turn approved commercial intent into an orderable legal customer without duplicating identity or coupling users to ERP availability.
Use an idempotent asynchronous command, with explicit pending and intervention states in CRM.
ERP controls legal creation. CRM owns the commercial lifecycle. The integration layer owns delivery state—not business truth.
02Premises & constraints
State what must be true before choosing.
The recommendation is valid only for this premise set. Change the premises and the answer should be allowed to change.
- 01Global operation
Multiple subsidiaries share commercial accounts, but transact through distinct legal customer records.
- 02Financial control
ERP validation is mandatory before an order; it may reject tax, credit or company-code data.
- 03Variable availability
ERP has planned maintenance and non-deterministic response times across regions.
- 04Human accountability
A commercial approver confirms readiness; operations owns unresolved integration exceptions.
“ERP owns the customer.”
ERP owns legal and transactional customer identity. CRM can still own prospect identity, relationship context and commercial status. Authority is a matrix—not a trophy awarded to one system.
03Second-layer questions
What “create customer” leaves unsaid.
- Q01
What exists before the ERP ID?
- Q02
Can two subsidiaries share a party but not a customer number?
- Q03
Does a timeout mean failure—or an unknown outcome?
- Q04
Who may edit tax data after creation?
- Q05
What blocks the first order while state is pending?
- Q06
How does support replay without creating a duplicate?
- Q07
What does the seller see when ERP is unavailable?
- Q08
Which event makes analytics count an active customer?
04Identity & boundaries
One company. Three useful identities.
Account
Relationship, pipeline and intent. Created early; CRM authority.
Party
Registered organization and tax identity. Validated before transacting.
Customer
Company-code, sales-area and payment context. ERP authority.
Hover or focus a system to see what it owns, what it does not, and which flows it takes part in.
05Candidate architectures
Three designs can work. Only one fits these premises.
| User wait | Blocks on ERP | Approval completes | Approval completes |
|---|---|---|---|
| Failure recovery | User retries | Managed replay | Next batch |
| Consistency | Immediate | Eventual + visible | Delayed |
| Operational load | Low initially | Explicit queue ownership | Reconciliation-heavy |
| Best fit | Stable, fast dependency | Variable global operations | Low urgency, bulk |
Variable latency across regions, and a process that can continue while legal creation completes.
- CRM must show Pending, Created and Intervention required as real states.
- Support owns a replay queue with reason codes.
- Order entry is gated on the canonical ERP number.
The asynchronous choice is not inherently “more modern.” It fits because business approval must remain responsive while legal creation is recoverable and independently observable.
06Recommended design
Acknowledge intent. Reconcile the outcome.
- 01Commercial approval
- 02Creation command
- 03ERP validation
- 04Outcome event
- 05Ready to order
- Freeze the creation payload.
On approval, CRM creates an immutable request snapshot and an idempotency key scoped to the legal entity.
- Accept; do not pretend to finish.
The integration boundary acknowledges durable receipt. CRM moves to
Creation pending—no fake success. - Resolve uncertain outcomes.
Before retrying a timeout, query ERP by the external request key. A delayed success must never become a duplicate.
- Publish a business-readable outcome.
Success carries canonical identifiers. Rejection carries stable reason codes and a repair owner—not a stack trace.
07Failure semantics
Design the recovery path before the happy path.
Never ask a user to resolve an uncertain distributed-system outcome by pressing “Create” again.
08Operating model
The support model is part of the design.
Owns process readiness, approval policy and communication with sellers.
Owns legal validation rules, duplicate resolution and transactional attributes.
Owns transport health, replay controls, correlation and service-level telemetry.
Observe business state, not only infrastructure.
- Requests pending beyond expected regional latency
- Rejection rate by stable business reason
- Unknown outcomes awaiting reconciliation
- Manual intervention age and accountable team
- Duplicate candidates and resolution time
09When I would choose differently
Architecture should move when the context moves.
If ERP provides deterministic, idempotent, highly available creation—and users cannot proceed meaningfully without its immediate result.
If creation has no same-day operational urgency, volumes are high, and the business already works in controlled master-data windows.
If an enterprise master-data service becomes the governed issuer of party identity across CRM and ERP.
Do not model system availability as business truth. Model intent, progress and outcome separately.Make ERP customer creation asynchronousSeparate commercial identity from legal customer identityControlled regional variation, multi-motion opportunities, customer identity, access and visibilityGrain and commercial intelligence, KPI writeback, segmentation reconciliation, multi-currency evolution