Engineering guides
A CRM and ERP data mapping example for the sales-to-operations handoff
Methodology: An original vendor-neutral design example using synthetic identifiers and explicit business rules. It is not a customer case study, a provider compatibility claim or production-ready connector code.
Use the downloadable integration procurement pack alongside this example. Its CSV field map makes ownership and matching decisions editable, while its acceptance worksheet starts every case NOT RUN. The synthetic JSON demonstrates requested values only, with invoice and payment evidence deliberately unverified. Discuss CRM/ERP implementation scope after agreeing that boundary.
CRM/ERP integration starts with ownership of business facts. Copying every field both ways creates conflicts, not a shared source of truth. Define one handoff, identify the records and choose a direction for each field. StackEndBox's CRM and ERP integration service implements that boundary around the APIs and editions you actually have.
Start with one approved business event
Consider a synthetic service business using a CRM for sales and an ERP for orders and accounting. When an authorised salesperson approves a deal, operations should receive an order request. Sales should later see selected fulfilment and invoice statuses. This does not mean sales may change a posted invoice, and it does not mean an invoice is paid. The example is a design exercise with no real customer, invoice or provider account.
| Business fact | Authoritative source | Direction and rule | Exception |
|---|---|---|---|
| Customer identity | Approved cross-system mapping | Map CRM company C-104 to ERP account A-208. Persist both identifiers. | No match or multiple candidates goes to review. |
| Sales owner | CRM | CRM to integration context. Do not replace the ERP account owner unless explicitly scoped. | Inactive user requires a named reassignment rule. |
| Legal billing details | ERP after account approval | Expose only agreed fields back to CRM, with read-only ownership. | A CRM edit becomes a change request, not an automatic overwrite. |
| Order request | Approved CRM deal revision | Create from deal D-701 revision 3 after validating required fields. | Changed revision or uncertain result needs reconciliation. |
| Product or service code | ERP catalogue plus agreed mapping | Resolve CRM line item to an approved catalogue entry. | Unknown code is held, not silently replaced with a generic item. |
| Currency and amounts | Approved request plus ERP validation | Transmit explicit currency and agreed units. Preserve decimal and rounding rules. | Mismatched totals or currency blocks the handoff. |
| Fulfilment state | ERP | ERP to CRM as a selected status with a freshness timestamp. | Unknown or stale status is visible, not presented as complete. |
| Invoice and payment state | Authoritative accounting/payment records | Map each supported state explicitly. Keep issued, paid and settled distinct. | A generic success response does not establish a financial event. |
Matching by company name alone is fragile. Names change and two customers may share a name. Email can also be shared, changed or absent, and a contact is not necessarily an ERP account. Select a stable mapping and a controlled exception path. HubSpot's contacts API documentation distinguishes records, properties and associations. Verify the corresponding object model and identifiers for both of your actual systems.
Separate delivery from the business operation
A webhook delivery ID, a deal revision and an order request are different identities. The same deal may have several legitimate revisions, and several deliveries may describe the same revision. Define the intended business operation using the source account, source record, approved revision and action. Keep a separate attempt history. A unique delivery ID alone cannot establish that an order must never be created twice.
| Observed state | Safe operator action | Evidence before proceeding |
|---|---|---|
| Validation rejected | Correct the missing or conflicting field and review a new approved revision. | No provider write occurred and the rejected field is recorded. |
| Prepared, not submitted | Review the exact mapping and submit through the controlled workflow. | Actor, source revision, target and action agree. |
| Submitted, response lost | Check the same saved operation and supported destination lookup. | Do not generate a new operation reference or repeat the write blindly. |
| Destination record verified | Display the saved target ID and reconciled result. | The intended target exists and matches the approved operation. |
| Destination conclusively rejected | Use the provider's documented correction/recovery procedure after review. | No successful or still-pending operation could be duplicated. |
| Inconclusive | Hold for owner or provider review. | No safe duplicate-prevention claim can be made from a timeout alone. |
Provider behaviour matters. Stripe's webhook documentation describes duplicates and out-of-order events for its service. That is a useful reason to test event handling, not evidence that every CRM or ERP offers the same IDs, retry policy or idempotency window. Establish lookup and retry semantics for the destination before promising recovery. Where they are insufficient, stop uncertain work for review.
Prevent loops and outdated updates
Choose one owner per field and record origin, revision and processing state where supported. An ERP status copied into the CRM should not trigger the reverse order-creation workflow. Define behaviour for a late revision, a clock discrepancy and a record changed during processing. A timestamp alone may not establish ordering across different systems. Use supported versions or a documented conflict policy instead of assuming last-write-wins is correct.
Treat initial import as a separate release stage
- Inventory objects and permitted fields, including archived records and custom fields.
- Export an authorised baseline through a secure process. Keep customer contents out of public tickets and diagnostic logs.
- Resolve duplicates and ambiguous mappings with the business owner. Record decisions rather than silently merging accounts.
- Run a dry mapping and validation pass in a safe environment. Separate accepted, rejected and unresolved records.
- Import only reviewed records and compare identifiers, counts and agreed control totals.
- Account for changes made during the import window with an explicit delta or freeze procedure.
- Release ongoing processing only after reconciliation and operator acceptance. Keep a pause and recovery plan.
Rollback may mean stopping the integration and reviewing records already created. Deleting newly created orders is not automatically safe once fulfilment or accounting work has started. Agree correction and compensation with the relevant business owner. Preserve the pre-cutover mapping and operation references, and distinguish reverting code from undoing business effects.
Compare proposals using acceptance evidence
- Replay one source event, then inspect target count and operation history.
- Send an older revision after a newer one and check the final approved state.
- Try missing customer and catalogue mappings and demonstrate owner correction.
- Interrupt a destination response after acceptance and check saved state without a second write.
- Expire test authorisation, reconnect through the supported process and review pending work.
- Pause processing, refresh the operator interface and reconcile the same outstanding operations.
A native connector may already meet these needs. Compare its supported objects, account editions, failure handling and maintenance with a middleware or custom approach. Avoid paying for bespoke work merely to reproduce a supported configuration. The API integration checklist helps define this choice before estimation.
Bring a concrete handoff to the scoping call
Share the CRM and ERP names, editions, first workflow, approximate volume and most costly exception through CRM/ERP integration. Keep credentials and customer records out of the first message. If information begins in PDFs or forms, first define a reviewed document-processing boundary. If the internal workflow itself needs replacing, consider custom CRM development separately.