A salesperson updates a customer’s details in the CRM. Finance corrects the same account in the ERP. Both records are valid from someone’s point of view. Which version should the integration copy?
This question can be more consequential than which connector to buy. An integration moves disagreements between systems as efficiently as it moves useful data. Before connecting a CRM and ERP, define the business rules that determine what a correct record looks like.
Start with one transaction, such as turning an accepted quote into an order. Follow it through both systems and identify where a person currently checks, changes or approves something. Those decisions need to survive the automation.
Assign ownership at the field level
It is tempting to declare the CRM the source of truth for customers. In practice, different parts of the customer record may have different owners.
The CRM might own sales contacts and relationship notes. The ERP might own the billing account number, credit status and invoicing address. A warehouse application may own stock availability. These are possible arrangements, not defaults that fit every company.
For each important field, record the system that can authoritatively change it, the direction of the update and who handles a disputed value. If both applications can edit the same information, define a conflict policy deliberately. “Use the latest timestamp” can overwrite a correct value with a later but less reliable entry.
Keep information that has no operational purpose out of the sync. Copying every field increases the amount of sensitive data you store and the number of mappings you must maintain.
Match records with stable identifiers
A customer name is not a dependable link between systems. Names change, spelling varies and unrelated businesses may have similar names. An email address is also a poor permanent identifier for a company account.
Agree how the integration will map each source record to its destination record. Preserve that mapping when names and contact details change. Decide what happens when one business has several legal entities or purchasing locations.
Historical records require separate attention. If the same customer already exists twice, connecting the systems will not tell you which record should survive. Profile a representative sample before estimating the migration. Include incomplete records, merged accounts and old transactions rather than checking only the cleanest examples.
Data cleanup needs a business owner. Developers can flag inconsistent addresses, but they may not know which address finance is authorised to use.
Define what a status actually means
“Won,” “approved” and “confirmed” can sound equivalent while triggering different obligations. A won opportunity might still need a purchase order. An accepted quote might contain a product that is no longer available.
For an order integration, write the prerequisites for creating the destination order. Specify which system acknowledges acceptance and what the sales team sees while the request is pending.
Also distinguish a technical failure from a business rejection. An unavailable API may justify a later retry. A blocked customer account usually needs someone to act. Repeatedly submitting the same blocked order is unlikely to fix it.
Give users a status that reflects the actual stage. “Sent to ERP” and “accepted by ERP” should not become the same green tick.
Choose freshness requirements by business consequence
Not every field needs instant synchronisation. A customer-facing stock promise may need much fresher information than a monthly account summary.
For each flow, ask how old the information can be before someone makes a bad decision. Then check whether the source system’s API, event notifications and rate limits can support that requirement. “Real time” is not a useful acceptance criterion without an agreed delay and a way to measure it.
A scheduled transfer can be suitable for low-urgency records. Event-driven updates can reduce delay where timely changes matter. Either approach still needs a way to detect missed or inconsistent records.
Agree what users should see during an outage. An explicit pending state is often more useful than silently displaying an old value as current.
Design recovery before the first failed request
Suppose the ERP creates an order but the response never reaches the integration. Retrying the request might create a second order unless the operation is protected against duplication.
Microsoft’s retry-pattern guidance explains why retry safety depends on idempotency: repeating an operation must not create unintended extra effects. It also distinguishes temporary failures from conditions that need another response. For a business integration, ask the team to demonstrate duplicate protection and bounded retries, not simply state that retries exist.
Unresolved records need a visible queue, a reason for failure and an authorised way to correct and replay them. The person operating this queue needs enough context to act without searching raw server logs.
Add reconciliation as a separate control. Compare records across systems periodically so an undelivered update can be detected even when no error was reported. Successful API requests are useful evidence, but they do not by themselves prove that the business records agree.
Test the awkward cases before enabling every account
Prepare a test set that includes the situations your staff currently handle manually:
- An existing customer whose name has changed.
- A quote containing an inactive product code.
- An order submitted twice after a timeout.
- A change made while the receiving system is unavailable.
- A cancellation received after fulfilment has started.
- Historical records with incomplete identifiers.
For each case, define the expected record in both systems and the action available to staff. Include an initial data transfer as well as ongoing updates. A sync that works for new accounts may still fail on years of existing data.
Roll out a limited flow first. Establish how you will stop new transfers, find partially completed operations and resolve them without losing valid work. Do not rely on switching the connector off as a complete rollback plan.
Choose the implementation after the rules are clear
A native connector may cover the required objects and directions. An integration platform may provide useful monitoring and reusable adapters. Custom development may be appropriate for business rules or systems that the standard options do not support.
Evaluate these choices against the actual workflow. Ask whether error handling, reconciliation and field ownership can be configured without fragile workarounds. Check who maintains the integration when either vendor changes its API.
Our custom versus off-the-shelf guide provides a broader buying framework. For integration work, the most useful material to bring to Five Bricks is a sample transaction, the systems involved and the rules people currently apply by hand.
Describe that flow in the client intake form. Keep confidential customer data out of the initial submission; anonymised examples are enough to explain the problem and discuss the next investigation.