CRM and ERP Integration

How an Integration Project Actually Runs

The first pass is an inventory rather than a design. Every object that will move gets listed with a direction: customer records from CRM to ERP, invoices back the other way, products one way only. Against each one, record what the API actually exposes, because the field list in the user interface and the field list in the API are not the same thing. Calculated totals, tax figures and system audit fields are commonly read-only through the API, and custom fields usually carry an internal name that bears no relation to the label on screen.

Mapping is field to field and also value to value. An order status picklist in one system has to resolve to a picklist in the other, and the value with no counterpart is the interesting one. Types matter more than they look: length limits truncate silently on some platforms and reject the whole record on others, dates arrive with or without a time zone, and currency rounding applied at different points produces invoices that differ by a cent and reconcile to nothing. Required fields on the receiving side are the usual reason a mapping that looked complete fails on its first write.

Build order is one flow, end to end, in a test environment, before the second one is started. That means the first flow carries its own error handling and its own monitoring before anything else is added, so that when something is wrong there is one change to look at. What that sequence needs from your side, before the first flow is built:

• A test or sandbox instance of each system, or a clear statement that none exists.
• API credentials for each system, and the administrator access needed to issue them.
• One person per system who can decide field ownership without convening a committee.
• An export of real records, including the awkward ones nobody wants to show.
• Agreement on which system is written to first where a flow runs in both directions.
• A decision on history: backfill everything, backfill from a date, or start clean.

Matching Records Across Two Systems

Every sync answers the same question on every record: is this the same customer we already hold? That needs a key both systems can carry. Email addresses look like keys and are not, since one person uses two of them and two people share one at a small company. Company names are worse, because punctuation, legal suffixes and trading names differ by system. The durable pattern is to write the far system's record ID into a dedicated field on each side the first time a record crosses, then match on that field afterwards.

Unmatched records need a rule before go-live rather than during it. When a record arrives with no counterpart, the options are to create one on the far side, or to hold it in a review queue for a human. Creating is right where the far system is only a destination and a wrong creation is cheap to undo; a queue is right where it is not. Fuzzy matching on name and address is a third option, and it belongs feeding that queue as a suggestion rather than acting as an automatic decision.

Deletions and merges are the cases most projects find late. Many APIs report a delete weakly or not at all, so a record removed in one system can persist indefinitely in the other. Soft deletes, where the record is flagged inactive instead of removed, propagate cleanly and are worth preferring on the source side for that reason. Merging two duplicates in a CRM behaves as a delete plus an update: the losing record's ID stops resolving, and any cross-reference stored against it becomes a dead pointer that the next run will try to follow. The deletion rule has to be designed rather than inherited.

How the Two Systems Exchange Records

Three transports cover almost everything. A push, where the source system calls a URL of yours when something changes. A pull, where the integration asks on a schedule for records modified since a given timestamp. And a file drop, still common with older ERP and accounting products, where a delimited or fixed-width file lands on SFTP and is collected. Which one you get is usually decided by what the source system supports rather than by preference.

Webhooks deliver at least once, not exactly once, and they arrive out of order often enough to matter. A retry after a network blip means the same event can arrive twice, which is harmless only if the write path matches on the stored cross-reference instead of creating blindly. Most webhook payloads carry an ID and a change type rather than the full record, so the handler calls back for current state, which is also why two edits in quick succession can both read the later version. And there is usually no replay for the window during which your endpoint was down, so a push-based flow still needs a scheduled pull behind it to collect what was missed.

Polling turns on a timestamp, and whose clock that timestamp comes from decides whether records go missing. Use the modified date returned by the source system, not the time your job started, and overlap each window by a few minutes so records written while the previous query was executing are not skipped. The overlap re-reads a handful of records every cycle, which costs nothing once writes match on the cross-reference.

API rate limits shape the design more than anything else in this list. Platforms return HTTP 429 when a limit is hit, usually with a Retry-After header stating how long to wait, and a client that ignores it and retries immediately extends its own lockout. The quota is normally counted per organization over a rolling window and shared with everything else connected to that org, so the budget available to your integration is whatever the reporting tool, the mobile clients and the other vendor's app have left. Bulk and batch endpoints, where the platform offers them, move hundreds of records for the cost of a few calls and are the right home for anything nobody is waiting on. A one-time backfill is the usual way a quota gets exhausted, which is the argument for running it in chunks rather than as a single job.

Credentials, Permissions and the Service Account

An integration authenticates as somebody, and the choice of somebody has consequences. A token issued against a named employee's account inherits that person's permissions and stops working when their account is disabled, which is how an integration that ran quietly for a year fails on the Monday after someone leaves. A dedicated service account, owned by a role rather than a person, avoids that. On platforms that charge per user, the license for it belongs in the budget from the start rather than arriving as a surprise at go-live.

Permissions on that account then decide what the mapping can actually do. Field-level security and role-based record access apply to API calls exactly as they apply to the screen, so a mapping built and tested by an administrator can drop fields or return empty result sets once it runs as a restricted service account. The symptom is characteristic: no error, a successful response, and a field that is simply absent. Granting only the objects and fields the flows use is still right; the point is to test as the service account rather than as yourself.

Token lifetime is the other recurring failure. OAuth access tokens are short-lived and refresh automatically, but the refresh token itself can expire after a period of inactivity, be invalidated by a password change on the underlying account, or be revoked when an administrator resets connected app access. Any of those stops the flow cleanly and quietly, which makes it a monitoring problem as much as an authentication one. Where the ERP sits on your own network, the same thinking applies to whatever certificate or VPN credential the connection depends on, since those expire on a fixed date whether or not anyone noted it.

When You Do Not Need an Integration

Volume and edit frequency decide this more than anything else. A flow carrying a handful of records a week, where nothing about the record changes after it lands, rarely repays the attention automation asks for across its life. An export and an import with a checklist can be the honest answer, and it carries no software to maintain. What turns that judgment around is not volume by itself but the second edit: once the same record is changed in both places after the first copy, keeping up manually becomes a reconciliation problem rather than a typing one, and reconciliation is where the errors hide.

There is also the case where nobody actually needs to edit in the second system. If the requirement is to see figures from the CRM and the ERP together, and neither system needs to accept writes from the other for that to be satisfied, then what is being asked for is a reporting question rather than a sync question. Naming which one it is at scoping matters, because the two are specified differently and the answers are not interchangeable.

Signals that the manual version has stopped working, and that a flow is worth building:

• The same record is touched by more than one team, each keeping its own copy.
• Discrepancies surface at month end rather than at the point they were created.
• Someone maintains a spreadsheet whose only purpose is holding the two systems together.
• Headcount is being added to keep pace with a volume that is still rising.