Connecting a CRM to an ERP looks straightforward in a demonstration: a sales opportunity becomes an order, and the order appears in the next system. The difficult questions arrive later. What happens when the receiving system is unavailable, the same message arrives twice, or a customer changes their billing details halfway through the process?
A useful integration must make those situations understandable and recoverable. The business goal is less manual work with reliable records, not merely a successful API request. Start with one important workflow and define its failure behaviour as carefully as its normal path.
Decide which system owns each fact
A CRM may own the sales conversation while the ERP owns invoice numbering and payment status. Trying to let both systems freely overwrite every field creates ambiguity. A shared customer does not imply that every customer attribute has the same owner.
Create a field map that records the source, destination, transformation and conflict rule. For a company name, decide whether a sales edit should change an existing invoice record. For an address, distinguish the contact address from the billing and delivery addresses. Define what happens when a required field is missing.
Use stable identifiers to connect records. Names and email addresses can change, and multiple people can share a business address. Keep a mapping between the identifiers used by the two systems rather than repeatedly guessing whether two similar records refer to the same customer.
Define the event that starts the work
“When a deal changes” is often too broad. A better trigger might be “when an approved deal first reaches the ready-for-order state.” Specify who can reverse that state and what an update means after the ERP has already accepted the order.
Write the flow in business language: approved deal, validated customer, created order, stored ERP reference, visible result in the CRM. Identify where a person must intervene. This helps sales and operations agree what “synchronized” actually means.
Some systems deliver webhooks, while others require periodic API checks. Record the acceptable delay before choosing the mechanism. A daily reporting feed and a stock reservation have different timing needs.
Expect repeated and out-of-order messages
Do not assume an event is delivered exactly once or in chronological order. Stripe, for example, explicitly documents duplicate deliveries and does not guarantee event ordering. Its webhook documentation is a useful concrete illustration; check the equivalent guarantees for every provider you integrate.
Imagine an ERP creates an order but the response to your integration times out. Retrying blindly can create a second order. The integration needs a way to recognize that the business operation has already happened.
An idempotency key identifies one operation across retries. Stripe’s idempotent request documentation demonstrates this API pattern. When the destination has no such feature, use a stable external reference and a controlled reconciliation process; a quick “check, then create” can still race under concurrent requests.
Keep event identifiers and business operation identifiers distinct. Two different events may describe changes to the same order, while one event may be delivered several times. Decide how updates are sequenced and how an older update is prevented from overwriting a newer state.
Separate receipt from completion
A receiving endpoint can acknowledge a message after it has been validated and saved durably for processing. Long-running work can then happen in a worker. If the system acknowledges before saving the message and then crashes, the provider may believe delivery succeeded while the work is lost.
Use bounded retries for temporary problems and a separate path for errors that need correction. An unavailable service may recover; a missing customer identifier usually needs a data fix. Retrying the latter indefinitely consumes capacity without moving the order forward.
The person handling exceptions needs a useful view: affected record, operation, last attempt, reason for failure and the next action. A retry control should preserve the duplicate protection of the original operation. Access to credentials and sensitive payloads should remain limited to the people and services that need them.
Monitor business completion, not only server health
A running integration process can still be failing every order. Track completed operations, outstanding work, the age of the oldest pending item and failures requiring attention. Agree an alert threshold with the operational team rather than sending a message for every temporary retry.
Add a periodic reconciliation between the systems. For example, compare approved deals with their recorded ERP references and investigate gaps. This can expose an event that never reached the integration, a manual change or a defect that ordinary error logs missed.
Logs should help reconstruct one operation using a correlation identifier, without dumping entire customer records into every message. Assign an owner for the integration and document how the team handles a provider outage.
Test the unhappy paths before expanding
For the first workflow, demonstrate a duplicate delivery, a timeout after creation, a temporary outage, an invalid field and an update arriving late. Confirm that a corrected record can be processed without duplicating the original action.
Only then add another workflow or system. This creates a repeatable operating pattern instead of a growing collection of one-off connections. Our custom software work and automation and integration services can support that foundation. Send us the two systems and the handoff you want to improve, and we can define a useful first integration.