Technical guide / Systems integration
Systems integration: what to check before connecting ERP and CRM.
A useful integration preserves the identity and meaning of data as it moves between applications. Before building, decide which system owns each field, which event triggers a change and how to verify the result.
Information that arrives ready to use.
- Source
- Agreement
- Destination
By Kenea · Published and reviewed: .
1. Identify who maintains each data item
ERP and CRM may both contain a “customer” while meaning different things: a sales account, an invoicing entity or several locations. An integration needs an explicit mapping. Matching display names do not guarantee that two records describe the same entity.
Prepare a field map with stable identifiers, formats, required fields and update direction. Decide which application is authoritative for each field. One system need not govern everything, but conflicts between changes proposed by two applications must be resolved.
| Data | Required decision | Example conflict |
|---|---|---|
| Customer identifier | How to link both systems’ references. | Two sales accounts point to one invoicing entity. |
| Address | Separate delivery, contact and invoicing addresses. | A sales update overwrites the delivery address. |
| Order status | Define transitions and who authorises them. | A delayed message changes “shipped” back to “pending”. |
| Amount | Agree currency, precision and components. | One system sends a total while the other expects a pre-tax amount. |
Rules must also cover archived records, changes and possible merges. Avoid starting with two-way synchronisation of every field when the process only needs one reference sent in one direction.
2. Review the connection method and its conditions
First check what the vendor provides for your version and service tier. A published API does not mean every operation is available on your plan, and an existing connector may cover only part of the path.
- Maintained connector: check objects, actions, limits, compatible version and incident ownership.
- API: review permissions, authentication, filters, pagination, rate limits and error responses.
- Events or webhooks: check authenticity, possible duplicates, ordering and recovery of missed notifications.
- File exchange: agree format, delivery, batch identification and import confirmation.
- Screen automation: assess interface stability, sessions, supervision and maintenance cost.
These methods can be combined. An event may signal a change and an API retrieve current data; an export may support the initial load. The choice depends on freshness, volume, available functions and operating conditions. “Real time” needs a defined and measured acceptable delay.
3. Preserve identity when an operation is repeated
The same request may arrive more than once after a retry, double click or process recovery. The integration must recognise which operation each attempt belongs to. Creating a new reference on every retry breaks that link and can create a second record.
Some APIs offer idempotency: a way to repeat a request under defined conditions without repeating its effect. Stripe, for example, documents idempotency keys and restrictions on content and retention. This is behaviour of that service; check the guarantees of your actual destination. Source: Stripe, idempotent requests.
Retain the source reference, destination reference and relevant attempts. If the same reference arrives with different content, define whether it is a valid change or a conflict. Discarding everything resembling a duplicate can lose a legitimate update.
4. Distinguish a rejection from an unknown response
If the destination rejects a field and returns a complete response, there is information to correct. If the connection drops after submission, the result may be unknown. A client stopping its wait does not prove that the server stopped working.
AWS explains why timeouts and retries need to be designed together: repeating calls with side effects may duplicate those effects, and bursts of retries can worsen overload. Procedures must limit and space attempts and check when repeating is safe. Source: Amazon Builders’ Library, Timeouts, retries, and backoff with jitter.
For an unknown operation, retain evidence and use the destination’s query or reconciliation facilities. If it provides no suitable mechanism, a review procedure is needed. An error queue should show what happened, how long it has been pending, who owns it and the next action.
Event delivery also needs attention. Stripe documents that its webhooks may repeat and arrive in a different order from their creation. This is a concrete reason to check each provider’s contract instead of assuming one guaranteed order. Source: Stripe webhook documentation.
5. Define permissions and operational visibility
The integration account should have the permissions required by its authorised path. Separate test and production environments, identify who renews access and avoid including keys or complete documents in support logs.
To follow an operation, its reference, participating systems, known state and attempt times are often more useful than a large data dump. Match detail and retention to the process. The team should be able to identify pending work without opening a developer console.
Also decide how to detect absence. If a source should produce a daily batch but none arrives, a system that only alerts on reported errors may stay silent. Check for expected activity when it matters.
6. Test the path before authorising production
| Scenario | Result to demonstrate |
|---|---|
| Normal operation | Correct data appears at the destination and remains linked to its source. |
| Repeated request | Identity is preserved without an unintended extra operation. |
| Lost response | The result stays unknown until queried or resolved through the procedure. |
| Invalid data | An actionable explanation is available; the same error is not retried indefinitely. |
| Out-of-order events | The final state follows the agreed business rule, not just arrival order. |
| Restart or expired access | Pending work is retained, the owner is informed and recovery is verifiable. |
A change already applied in another system may not offer a simple “undo”. Describe what can be reversed and what requires a compensating operation or intervention. Test achievable recovery and its limits before extending the scope.
What should be documented
A commissioned technical assessment should support the next decision: a process map, data mapping, available interfaces, dependencies, owners and outstanding tests. Unknowns should remain explicit; API access is not evidence of a completed integration.
An accepted implementation would also document versions, required configuration, test evidence and operating procedures. Kenea’s systems integration work starts with the existing software and the process objective. If documents also need interpretation, review the choice between rules and AI and our applied AI approach.
The free assessment maps an initial direction without registration. Understanding interfaces, permissions and feasibility requires reviewing real systems within an agreed scope.
Explore my process View solutions
Sources and limits of this guide
Primary sources consulted on 8 September 2026: Stripe, Idempotent requests; Stripe, Webhooks; and Marc Brooker, Amazon Builders’ Library, Timeouts, retries, and backoff with jitter (2019). Stripe’s conditions describe its own service and may change; they do not apply automatically to every ERP, CRM or API. The matrices and acceptance plan are Kenea proposals, not evidence of an executed integration.