What needs to be synchronized?
Orders, customers, payments, products and stock are separate entities. Define the source, direction, update trigger and failure behaviour for each. An ERP may own prices while a CRM user updates delivery details. These changes should not blindly overwrite each other.
- External order ID and product variants.
- Contact and delivery information with appropriate permissions.
- Statuses, payments, partial shipments and returns.
- Availability rules: physical stock is not always available stock.
Scenario: a retry creates a duplicate order
A store submits an order, receives no response and retries. If every attempt creates a record, a manager sees two purchases. We design stable external identifiers, processing records and safe retries. Matching only the phone number and amount is insufficient: a customer may genuinely place two identical orders.
Scenario: a return restores the wrong stock
A customer returns one item, but the integration marks the entire order as returned. Model quantities per line, money movement and product condition separately. A refund does not mean the product is ready for resale. Test partial returns, size exchanges and movement into inspection as distinct events.
Existing connector or custom integration?
Test an existing connector against your workflows first. If required fields or exceptions are missing, evaluate APIs and custom logic. For KeyCRM, Skynum, ERPNext, HubSpot, Pipedrive and Zoho CRM, verify the available objects and operations against documentation. For Dynamics 365, identify the specific application. Do not assume compatibility without checking permissions, plans and limits.
What happens when a system is unavailable?
Agree on which operations can be queued, who is notified and how records will be reconciled after recovery. A retry should finish pending work, not multiply orders. For inventory, agree on acceptable delay and store behaviour when availability is stale. “Always real time” is not a substitute for these rules.
What does acceptance include?
Test changes, retries and failures, not only one successful order. The deliverable is the agreed exchange, verified scenarios and instructions for the responsible person.
- Repeated and out-of-order events.
- Partial payment, cancellation and return.
- An unknown SKU or status.
- Recovery and checking for missing records.