What to watch for in ERP integration

Below is what we have learned from integration projects — the questions that determine whether the result is trustworthy.

Answer this first: which system owns which data?

This is the most important decision in an integration project, and it is a business decision rather than a technical one. For each type of data, one system has to be named as the source of truth.

• Accounts — usually the ERP, because tax details and accounting records live there. But new prospects are born in the CRM, so the rule for the handover has to be written down.
• Products and prices — almost always the ERP.
• Stock — the ERP owns it; the CRM only reads.
• Opportunities and quotes — the CRM owns them, and the ERP may not need to know about them at all.
• Orders — created in the CRM, passed to the ERP, after which the ERP owns them.
• Invoices and payments — the ERP owns them; the CRM reads.

Writing code before this table is settled leads directly to the “which one is right” argument later. What happens when a record changes in both systems at once also needs deciding up front.

Direction and frequency

Every flow needs two questions answered: which way does the data move, and how often?

Making everything bidirectional and real time is tempting and produces unnecessary fragility. Nobody notices if the product catalogue syncs once a day. But if stock data is a day old, the sales team sells something that is not in the warehouse.

• Needs real time: order transfer, stock queries, credit limit checks
• Scheduled is enough: product catalogue, price lists, account balances, invoice status

Real-time flows are both more expensive and more brittle. Do not choose them where they are not genuinely needed.

What if your ERP has no API?

A common situation, particularly with older installations. There are two routes.

Connecting directly to the database. It looks fast but we do not recommend it. The ERP’s data model can change with a version upgrade and your integration breaks without warning. Most ERP vendors also treat direct database access as outside their support scope.

Writing a middleware service. A small service running on the ERP server exposes a controlled interface. The ERP itself is not touched; reads and writes happen through defined endpoints. This is the route we prefer — the initial setup takes a little longer and it causes far fewer problems over time.

Error handling belongs in the design

The real test of an integration is what happens when things go wrong. The ERP server is down for maintenance, a record is missing a required field, the network drops — all of these will happen.

The worst outcome is a record disappearing silently. The order shows in the CRM, never reaches the ERP, and nobody notices. To prevent that, every flow needs the following.

• Failed operations written to a log
• Automatic retry logic
• Notification to a named person after a set number of attempts
• Pending records visible from inside Salesforce

Adding this layer afterwards is considerably more work than building it in from the start.

Matching rules

How the same record in two systems gets matched has to be defined up front. A tax number is often a good key for company accounts, but may not exist for individual customers. Products are usually matched on stock code, though it is common to find the same product defined under several codes in the ERP.

A weak matching key produces duplicate records, which is the most irritating failure mode an integration has. Cleaning the existing data before migration is an unavoidable step on most projects.

Rollout sequence

Do not open every flow at once. The sequence we recommend is this.

1. Start with a one-way, read-heavy flow — usually the product catalogue or account transfer. Low risk, high learning value.
2. Add stock and balance queries. The sales team feels the benefit immediately.
3. Open order transfer. Now you are writing data, so this needs care.
4. Connect invoice and payment status.

Validate each step in a sandbox and start with a limited group of users. When something fails, knowing which flow caused it is impossible if you opened them all together.

Checklist before you start

• Has an owning system been named for each data type?
• Is the conflict rule written down?
• Are matching keys defined and the existing data cleaned?
• Is API or middleware access ready on the ERP side?
• Who receives error alerts, and what do they do about them?
• Is there a test environment where changes can be validated?
• Have API call limits been calculated?

In short

Success in ERP integration depends far more on the clarity of the decisions than on the quality of the code. Once ownership, direction, frequency, matching and error handling are agreed, the rest is routine development. Skip those decisions and the integration will run, but nobody will trust what it produces.