Concurrency issues in a bi-directional Epicor-Salesforce integration can hinder your teams’ productivity, and mediating them isn’t always an easy barrier to hurdle. The main reason is that, although Epicor is an acceptable ERP system for many businesses, the Application Programming Interface (API) is limited when it comes to mapping. In most cases, the customer is unable to avoid round-robin updates and circular changes when Epicor is integrated with Salesforce. 

At RemoteCRM, we’ve seen this obstacle come up for a number of our clients who have had a hard time navigating through the mapping process. There are a few ways you can avoid this and help your organization leverage both systems for success without having to deal with the confusion of round-about updates.

Handling the Issue of Concurrency

The general situation we aim to solve is as follows: Salesforce sends data to Epicor (in the form of a query or something or another), and Epicor returns the same data to Salesforce, which in turn creates the circularity in updates and system changes. Ideally, when we have two systems syncing back and forth, we need to establish a flag system. A best practice is to use either a dedicated user to run the sync or a specific field to help indicate where the changes are happening.

Dedicated User Vs. Specified Field

For a dedicated user, any changes coming from that user ID will show us that the problem is a user error, and we don’t need to alter the system; instead, we need to modify the user’s actions. On the other hand, when we use a specific field to locate the error, we highlight that field by flagging an update (for example, update “=salesforce” or “=epicor”), which allows us to see where the update is coming from and stop the concurrency issue right there. If the update source is empty, however, we know the updates are coming from a user who is making changes within the system. 

Without having either of these two mechanisms in place, the data will continue to cycle. Salesforce will continue syncing the new changes into Epicor, and Epicor will continue syncing further modifications into Salesforce. Without implementing a protective mechanism, the data swirls in a vicious cycle, creating only confusion for your team and system.

Making Changes

Unlike Salesforce, Epicor does not have a bulk API, which means any changes to the system need to be done one-by-one. For administrators, this can be overwhelming, and whenever they pull changes from one system to another — especially in the case of Salesforce to Epicor — it needs to be done in chunks. Let’s say the administrator gets 1,000 changes that need to be pushed to Epicor; we can’t apply them all at once. Instead, the workload needs to be divided up and applied individually.

Using the Configuration File:

Another helpful tip is to build up the mapping and make it visible to the Salesforce administrator, so they can see each field and where it goes in the opposing system. In the case that they have a new field they’d like to sync, they don’t have to go into the code at all. Rather, they create the new mapping within Salesforce. This kind of mapping is focused on making the application as configurable as possible with specific configuration files. Even in the case that the users change their password (either in Salesforce or Epicor), or Epicor is moved to a different server with an updated URL, we can configure it without having to modify the code or causing any downtime.

  • Example: If the client finds an issue and they want the sync to keep running (but only from Salesforce to Epicor or vice versa), they can turn off one of the flows without having to cut everything off. In that scenario, a configuration file is vital.

Custom Integrations 

After all that, it’s a matter of tweaking and testing the integration. Integrations aren’t one and done projects; instead, implementation is always followed by fine-tuning and troubleshooting. Although a proper mapping right off the bat helps significantly, the customer doesn’t immediately know their system isn’t performing as it should, which is why this integration requires customization on both sides of the fence.
For the Salesforce side, XTIVIA can be your partner in optimizing your integration needs for your Salesforce to an ERP environment — Epicor or other. If your business needs a robust integration solution, feel free to reach out to today.