THE KEY ANSWER
Before integration, determine which system is responsible for each field, how you identify the same object, and what happens in case of a conflict. Design validation, retries, and a visible error queue. API access alone is not sufficient.
A single source of truth does not have to mean a single system
The CRM may be responsible for commercial relationship data, while the ERP handles settlement terms and order status. It is important that there is a clear rule for each specific piece of information. If both systems can modify the address, establish priority and the method for resolving conflicts. "Two-way" synchronization without these rules quickly creates overwrites that are difficult to explain.
Prepare a field map including format, requirement, and owner. Document semantic differences. "Active customer" in the CRM may mean an open relationship, while in the ERP it may mean the ability to issue a document. Integration should not assume that a similar field name implies an identical business rule.
Context and references: AWS Builders' Library: Making retries safe with idempotent APIs
Record identity is more important than similar names
Do not link companies solely by name, which can change and be duplicated. Choose stable identifiers and maintain mapping between systems. Plan for merging duplicates and situations where a record has been deleted or manually merged. The lack of such a procedure can cause old data to be recreated.
Demonstration example: a salesperson corrects a counterparty's name, but the integration recognizes them only by the old name and creates a new entry. Technically, every operation ends in success, yet the process generates duplicates. Therefore, acceptance must verify the business outcome, not just the HTTP response with a success code.
Retries must not duplicate effects
The network may interrupt the response after the target system has performed the write. Resending without operation identification may create a second order. Design a mechanism for recognizing duplicates and checking the result. This property is often referred to as idempotency.
Distinguish between transient errors and data errors. Service unavailability may justify a delayed retry. An incorrect customer number requires correction or a human decision. Repeatedly sending the same faulty record only increases load. Establish a retry limit and a place where the issue awaits processing.
Integration requires operational tools
The person handling the process should be able to see what did not synchronize, why, and what the next step is. A change history and safe retry of a single operation are useful. Do not require manual database intervention by a developer every time. An exception handling interface is often more important than a dashboard showing the number of successful calls.
Test the full cycle: creation, modification, cancellation, duplication, and delayed messages. Ensure event ordering and status consistency. After deployment, compare selected data between systems to detect silent discrepancies. The absence of a technical alert does not prove that every order reached the correct place.
WHERE TO START
Bring this into your project.
- Assign an owner to each field.
- Establish stable identifiers and duplicate handling.
- Distinguish between transient failures and invalid data.
- Provide history, an exception queue, and controlled retries.
Choose one thing your process is missing today. It's a useful topic for your first conversation with the team.
QUESTIONS AND ANSWERS
Frequently asked questions.
Does synchronization have to be immediate?
Not always. Match the delay to the process: delivery status may tolerate a different time than the reservation of the last item. The user should know when the data was updated.
Should AI map all fields?
Fixed mapping rules are better executed with predictable code. AI can help interpret unstructured content, but the result should pass validation before being written to the business system.
Sources and context
- AWS Builders' Library: Making retries safe with idempotent APIs ↗
AWS explains why retries require control over multiple executions. CRM and ERP mapping examples are ALGOV scenarios.
Prepared by the ALGOV team. Current as of September 8, 2026. Examples describe possible scenarios, not results from client projects. How we create our guides.
