Bidirectional ERP integrations fail less often because an API cannot move data and more often because two systems are both allowed to decide what the same field means. The hard part is not the connection. It is deciding which side wins when the connection works exactly as designed.
At first glance, a bidirectional (two way) integration sounds like it will cover all your bases. Customer information flows from the CRM to the ERP. Then the status of payments flow from the ERP back to the CRM. No one enters anything twice. Sounds good.
However, if someone changes a billing address in the ERP and a salesperson makes the same changes to their customer in the CRM, then both changes are legitimate. Both systems then send an update. At this point the issue is no longer technological. It is an issue of who gets to control each piece of information.
This decision must be made before anyone writes the first line of code for this integration.
The technical connection is the easy part
When starting to plan most integration pieces start with endpoints, fields, and frequency. Can the API read the object? Can the API write it? Is there a webhook?
These are important questions, however they are not the most important question that needs to be answered.
The most important question is what happens when both systems can make the same modification to the same piece of data.
A CRM may own the sales contact information. However, the ERP may own the legal billing name used on invoices. The commerce platform may own the shipping address for an open order. The ERP may own tax treatment. When the mapping document only says “sync both ways,” those distinctions get lost. This implementation has delegated a business decision to integration code.
If two systems can make modifications to the same field, you do not have two sources of truth. You have a dispute with a timer on it.
Every shared field needs one authoritative side
“System of record” is too broad to be useful by itself. A company can have one system of record for customers and still need different authority for individual fields.
Account owner and phone number may need to be owned by the CRM for sales. Credit terms, tax status and legal billing name may need to be owned by the ERP for finance.
For each field that crosses a system boundary three things need to have answers. What system can originate the value? Can the other system propose changes? What happens when the non-authoritative side makes a change anyway?
The last question is typically the one projects tend to skip over.
Not making any action will protect against conflicts but will cause confusion. Making an action (overwrite) may destroy useful work. Creating exception queues creates human decision-making processes; however, also creates a queue someone must manage/own.
There is no universal answer; however, there does need to be an answer.
Conflict rules matter before retry rules
Development teams are careful about failed deliveries. Development teams design retries, idempotent keys, and alerts. These actions protect the integration when a message does not arrive (deliver).
Conflicting messages are different. Both messages were delivered.
An example could be that the customer's address was changed in CRM at 10:02 am and then changed again in ERP at 10:03 am. If “latest update wins”, then the ERP update would win. This reasoning seems good until you consider that the CRM edit came from the customer and the ERP edit came from an employee correcting an old record. Timestamps cannot tell you which edit is more authoritative.
Conflict issues occur with all types of data including customer addresses, vendor details, project codes, payment terms, etc. Many of these fields affect taxes, cash or reporting in some way, therefore making them even more serious.
Conflict rules should be written in business language before being implemented as code. “ERP wins for payment terms” is a rule. “Newest record wins” is typically a short cut.
The safest two-way sync is usually narrower than buyers expect
When using more fields as bi-directional fields might appear to represent a more integrated solution. In reality, generally the opposite is true. A customer relationship management (CRM) application could send new customers and authorized business changes to an enterprise resource planning (ERP) application. The ERP could return billing status, outstanding balances and payments. As long as all the systems continue to function properly, they are not attempting to change the same financial facts in a way that would cause conflict.
The end goal is not to have all possible fields that can be edited by users sent back and forth between applications. The end goal is to establish a process which works seamlessly and does not create two locations where the same facts can occur at the same time.
Integration code can help prevent duplicate writes and circular references. However, it will not resolve conflicting ownership.
What to test before go-live
While normal testing of integration verifies that records can be moved from one system to another, it represents only half of what needs to be tested.
The second part is called destructive testing. This type of testing involves making changes to the same field(s) in both applications. This type of testing also includes simulating a single application being unavailable when making a change. Additionally, you need to delete a record in one application and then recreate it. Lastly, simulate sending an update with some missing fields instead of blanks.
After completing these tests, document what occurs. For every major object involved in the integration, the destructive testing should provide answers to the following questions:
- Which system “wins” in case of a conflict?
- Does the losing value remain visible? If so, how?
- Can a user view why a change was rejected?
- Will additional attempts at updating produce duplicates?
- What happens to deleted records and merged records?
- Who is responsible for resolving the exception queue?
- How do finance teams resolve discrepancies between the two systems later?
If any of the above items require an engineer to review log files prior to providing answers, then the integration has not been sufficiently developed for standard production use.
Where this argument is weak
There are legitimate examples where there is truly a requirement for simultaneous two-way editing of information.
Inventory is an excellent example. An e-commerce platform may reserve inventory while an ERP application updates inventory through receipt and adjustment transactions. Many service organizations create billable events that their finance organization later corrects.
Even though these types of scenarios may require multiple systems to perform simultaneous writing activities against the same data, it doesn't eliminate the problem of who has final decision-making authority over specific fields in each respective system.
Authority may vary based on transaction state, field, entity or time. While an open purchase order may be updated within commerce, once shipped the only place a purchase order can be updated is within the ERP application.
Regardless of how complex the authority structure becomes, it remains an authority structure nonetheless.
The integration is a control, not a pipe
An operating API provides proof that data can flow between systems. It provides no assurance that the company's stakeholders will accept the results of subsequent changes made to either system including retries and corrections made after six months of modifications.
This is why integration development requires collaboration across departments. Finance and Operations personnel need to collaborate with Engineering to determine who gets to decide about each field in each system. They must collectively determine who will manage exceptions and ultimately determine who will reconcile any differences between systems.
Therefore, the best integration is not necessarily the one that sends data in the greatest number of directions. Rather it is the one in which each critical field has a defined owner; each collision has a defined resolution; and each discrepancy can be easily explained without having to constructively recount a full month of history.
Determine who has ultimate decision-making authority first. Develop the synchronization afterwards.