ERP and CRM: agree on data rules before connecting them

System names do not define the brief

A request to connect ERP and CRM often arises when people enter orders or customer details manually. Before choosing a transfer method, walk through the actual process. Who creates a contact? When does a sales opportunity become an order? Which information should the customer see in the portal?

That conversation produces a map of events and data. It helps separate automatic transfers from human decisions. Transferring every available field in both directions can create more problems if nobody has defined the rules for updating it.

Every piece of data needs an owner

The same customer may have a different name, contact person or address in each system. During design, establish which system is authoritative for each field. Billing details may be managed in a different place from sales notes. The team responsible for corrections also needs to know the rule.

The integration must be able to recognise the same record. A matching email address or company name may not be a reliable identifier. Agree on record mapping, handling duplicates and what happens after deletion. These are process questions that technical access to an API alone cannot resolve.

Decide how current the information needs to be

Not all data needs to be transferred immediately. Product availability when placing an order can have different requirements from a daily summary. Transfer frequency affects system load, operating costs and behaviour during an outage. Agree on it based on how people use the information.

Users should understand what the displayed status means. If data updates at intervals, the interface can show the time of the last successful update. A critical step may require a fresh check. This turns a technical decision into a workflow people can understand.

Plan what happens when something fails

Test the connection with an unavailable system, invalid data and an interrupted transfer. Retrying the same request must not create another order without checking. The design needs a way to identify transferred tasks and rules for retries.

An error record should show what failed and who can act next. For a process spanning several systems, define what happens when one part succeeds and the next fails. Sometimes a step can be reversed; in other cases, a responsible person must review it. Include that procedure in both the brief and the tests.

Example flow: an approved order

Imagine that a salesperson approves an order in the CRM and the internal system needs to create a corresponding record. The integration needs to know which fields are required and how to identify the customer. If the internal system accepts the order but its confirmation never arrives, the next attempt must first recognise the step already completed.

This illustrative example shows why testing a successful API response is not enough. Tests also need to cover a lost connection, an incorrect identifier and repeated delivery. Users need to distinguish a status awaiting processing from one that requires data to be corrected.

Start with one complete flow

For the first scope, choose a complete workflow, such as transferring an approved order and showing its status back in the original system. You get a concrete result while validating mapping, permissions and error handling. You can then add more data and events.

At handover, ask for a description of the rules, an overview of the interfaces and an outage procedure. The integration will need maintenance when systems change. Agreed responsibility for transfers matters as much as the first successful run.

Put the topic into practice.

Related project: FaxCopy a.s.