Start with one change, not two entire systems
Choose a specific event: an approved customer is created, a billing address changes or an order moves to a new status. Define which fields should move, in which direction and within what time window. Overnight processing may suit one record, while another process needs up-to-date information sooner.
Assign an authoritative source and an owner for each field. Sales might own contact details while finance controls payment terms. Saying that the systems should synchronise is not enough. Agree what happens if someone changes the same field in the other system while a transfer is in progress.
Compare the conditions behind each route
| Route | Check first | Watch for |
|---|---|---|
| Existing integration | Does it support the required fields, direction and events? | An available connector may not cover every exception. |
| API or workflow integration | Are access rights, limits, error responses and support clear? | The interface still needs mapping, maintenance and recovery. |
| Import and export | Are the format, timing, versioning and processing confirmation adequate? | Receiving a file does not mean its records were accepted. |
| Screen-based RPA | Is the action permitted and is the interface predictable? | Screen changes, sessions and additional sign-in steps can require maintenance. |
A combination may be appropriate: a supported export for the records and a workflow for approval, for example. Do not choose screen automation simply because a demonstration is quick to build. Establish who will retest the process after application changes.
A customer identifier is not universal
Map the meaning, format and required values of each field. A CRM organisation identifier may need to be matched to an ERP customer account. Decide how that mapping is maintained and who resolves missing or conflicting values. A company name alone is not a generally reliable key.
Test a new customer, an existing customer, an amendment and a deliberately blocked account. Include unusual characters, long names and blank optional fields. A technically successful transfer can still leave the receiving system with the wrong information.
What if no confirmation comes back?
The source sends a change but receives no response. That does not prove that the change failed. Check the receiving system before sending the same instruction again. Where supported, a stable identifier for the operation helps prevent duplicate processing.
Make differences between source and destination visible and assign someone to resolve them. An invalid address may require correction; a temporary connection problem may justify a limited retry. Define those paths in advance, including the point at which a person takes over.
Discuss maintenance before selecting a solution
- Who owns accounts, permissions and connection credentials?
- How are errors reported without copying unnecessary customer data into alerts?
- Who checks changes to fields, screens and interfaces?
- How are totals and rejected records reconciled?
- Can an operator stop the process and recover it in a controlled way?
Ask the application suppliers which interfaces and automation methods they support. Being able to access a button or endpoint does not automatically mean unattended use is permitted. Include licensing, maintenance effort and reliance on individual employees in the decision.
Bring a concrete handover to the discussion
Prepare an anonymised example of the change, the applications involved and the current checks. Focus on where the handover breaks down. That gives you a basis for assessing whether an existing feature is sufficient or an additional integration is justified. Tool selection follows from that understanding.
Where does your data handover break down?
Describe the information that needs to move between your systems. We can explore the question together, even if the right approach is not yet clear.
Discuss your data flow