1. Follow one business journey
Moving data between CRM and ERP does not by itself create a reliable handover from sales to operations. Start with a single journey, such as turning an accepted quotation into an order or updating customer details. Establish where the record begins, what decision authorises the transfer and when another team can use it. Hakan's experience includes building a CRM connected to canias ERP from the ground up. A practical design begins with that business relationship and the information it needs, rather than an ambition to synchronise every field in both directions.
- Name the trigger, completion condition and decision owner.
- List the workflows that are outside the first delivery.
2. Assign authority field by field
A customer can exist in both systems while different teams control different attributes. A sales owner might be managed in CRM and payment terms in ERP; that is an illustrative choice, not a universal rule. Build a field dictionary covering the authoritative source, editing permission, transfer direction and conflict decision. Microsoft's guidance on domain boundaries highlights that the same concept can carry different meanings in different systems. Apply that distinction to your existing applications. It does not require a rewrite or a move to microservices.
- Specify how a change in both systems will be resolved.
- Define empty values, deletion and deactivation separately.
3. Make record matching explicit
The identity of the record being updated matters as much as the fields being transferred. Avoid merging customers solely because their names look similar. Define the cross-system identifier, initial matching process and owner of ambiguous matches. Review currency, units, address structure and status mappings against concrete examples. For an unmapped value, decide whether the transfer should stop or move into a review queue. A silent default can hide a business decision. Keep the mapping rules readable to process owners as well as developers, with changes recorded over time.
- Check initial migration separately from ongoing updates.
- Assign an owner for duplicates and unmatched records.
4. Decide how fresh the information needs to be
Different workflows tolerate different delays. Availability used during an order conversation may need a different refresh pattern from a weekly customer classification. Agree acceptable latency for each flow and show users when information was last updated. Sent, received and completed in the destination are different states; the interface should not collapse them into one reassuring tick. Plan what people see during an outage. Choose the transfer approach around available interfaces, volume and operational need, then measure it against the agreed expectation rather than an undefined promise of real-time integration.
5. Treat recovery as part of the integration
A lost connection may require the same request to be sent again. Design repeat handling so that a retry does not accidentally create another customer or order. Keep a trace of completed steps, failure reasons and retry status. When part of a process has already succeeded, resetting everything is not always the right business response. Microsoft's guidance on compensating transactions explains why recovery depends on business rules and sometimes requires human intervention. Give uncertain cases a visible review queue, with enough context for the responsible sales or operations colleague to make a decision.
- Define who can retry, cancel or correct a transfer.
- Show the required next action alongside the technical error.
6. Accept the working process, then hand it over
Acceptance should cover normal operation, repeat submission, missing fields, outages and conflicting changes. Have process owners confirm the business result in both applications. Include the operational view, unresolved-error list, access ownership and change history in the handover. Agree what the team will monitor after launch: pending transfers, the oldest unresolved failure, unmatched records and resolution time are useful candidates. Establish a baseline before setting targets. Judge the work by whether the agreed process completes reliably, rather than attaching an unsupported savings percentage to a successful connection test.
