Connect your store and ERP: plan the data flow

1. Decide which system owns each data area

Assign ownership of product records, sellable inventory, pricing, orders, shipping and refunds. These may originate in different systems. Document who can change each value and which systems only consume it.

Avoid a blanket requirement to “sync everything”. Two systems can exchange data successfully while still producing conflicting prices if both independently overwrite the same field.

Build an ownership matrix by data object and, where necessary, by field. An ERP might own product identifiers while another system owns editorial descriptions. Include exceptions: who may correct inventory during an incident, and how will the next transfer avoid silently overwriting that correction?

Resolve conflicts before implementation. Should a later store price or address change be sent back to the ERP? Is there a point after which an order can only be edited in the ERP? These are business rules, not decisions that can safely be inferred from the available API fields.

2. Map workflows before listing fields

Follow an order from store entry through ERP acceptance, reservation, warehouse release, tracking and completion. Treat cancellations and returns as workflows in their own right.

For each handoff, define the trigger, required data, acknowledgement and acceptable delay. An overnight update might be sufficient for one report while sellable inventory requires a different update schedule.

For each object, decide whether creation, updates and deletion need to be exchanged. Describe how variants, bundles and multiple stock locations map between systems. Identify the data that must exist before processing can continue. An order with an unknown product reference should not quietly move forward as an incomplete order.

Distinguish notifications from state. “Inventory changed” is an event; the current sellable quantity is a state that should be retrievable and reconcilable when needed. Capture that business distinction in the brief, then ask the implementation team to confirm the mechanism and update frequency appropriate to the systems involved.

• Match products and variants through stable identifiers.
• Distinguish physical, reserved and available inventory.
• Agree the meaning of status values in each system.

3. Compare connectors, middleware and custom work

An existing connector can be useful when it supports your versions and workflows. Check its actual scope: exporting an order does not necessarily cover partial shipments, returns or later changes.

Middleware can bring several connections and transformation rules together. Custom development may suit unusual requirements. Compare setup, maintenance, adaptability and ownership against the same workflows rather than counting the interfaces in a product brochure.

Ask for a coverage list against your own scenarios. Separate standard functionality, configuration, additional development and unsupported cases. Establish who pays for and maintains changes when either system alters an interface or data model.

Consider how independently your team can operate later. Can it identify failed mappings, understand transformation rules and export required records? Who retains the configuration and documentation if the implementation partner changes? Compare ongoing licences and managed operating services alongside setup costs. A long list of supported systems does not demonstrate support for your workflow.

4. Plan for failures and repeated messages

Suppose the ERP receives an order but its acknowledgement is lost. Sending the order again must not automatically create another one. Ask how the integration recognises previously handled work and makes its outcome visible.

Shopify’s webhook documentation notes that events can arrive out of order and deliveries can be missed. For integration planning, that means backlogs and differences need a way to be detected and reconciled. The appropriate mechanisms depend on the systems involved.

A useful error message identifies the affected record, the problem and the next possible action. An unknown SKU is different from a system that is temporarily unavailable: one needs corrected data, while the other needs a suitable retry process. Repeating failed work indefinitely without making it visible does not resolve every kind of fault.

Include a periodic business reconciliation: which orders are missing, which statuses disagree and which inventory records differ? Define the lookback period and who can approve a correction. Keep integration access limited to the data and operations the connection actually requires.

5. Agree business acceptance cases

Test a normal order alongside difficult cases: a changed delivery address, unavailable variant, partial shipment and a return after the order has closed.

For each case, write down the expected result in the store, ERP and warehouse where relevant. A successful technical transfer is not enough if the stock position or order handling is wrong.

Use a manageable set of representative test records: simple and multi-line orders, several variants, different stock states and the exceptions your operation needs. Document starting conditions, action and expected outcome in every system. The same cases can then be repeated after a change.

Test recovery after an interruption as well. Does an acknowledged order get created again? Can an older update overwrite a newer one? Can a deliberately invalid record be corrected and reprocessed without replaying everything? Assign someone to approve each business outcome and specify the evidence they will need.

6. Include ongoing operation in the scope

Decide who will see failed transfers, resolve them and restart processing when appropriate. The store team needs understandable messages and a contact it can reach, not just an inaccessible technical log.

Include tests before system upgrades, credential maintenance, documentation and handover. Ongoing responsibility belongs in the proposal alongside the initial implementation.

Agree which conditions generate an alert and who handles them during which hours. A log without a responsible person is not an operating process. Separate technical incidents from business queries and decide who may approve a temporary workaround for a blocked order.

Use a controlled change process: describe the request, identify affected data flows, test representative cases and approve the release. Keep documentation aligned with the actual connection, including field mappings, status rules, access ownership and known limits. Passwords and other secrets do not belong in generally accessible project documents.