Integrations
Connecting a helpdesk to WMS, ERP, and store platforms: a safe data model
How to design commerce helpdesk integrations: sources of truth, APIs, normalisation, read-only mode, degraded states, and safe operational actions.
Faboxi product team · 8 min read ·
Short answer
A helpdesk should not own order truth or connect directly to WMS or store databases. A safe model uses versioned APIs and connectors, maps facts into a shared model, exposes source health, and starts read-only. Any order-changing action requires preview, permission, idempotency, audit, and commerce-system confirmation.
What the integration changes for a store owner
An operator should not copy an order number across several tools. The integration should bring the right facts into the conversation, expose freshness, and make failure explicit. A read-only first stage validates data quality without risking order changes.
Assign ownership for every kind of data
The helpdesk owns conversation, case status, assignment, SLA, and operator decisions. The store, ERP, WMS, payments, or fulfilment system owns the corresponding commerce facts.
Why connectors beat direct database access
- A versioned contract.
- Tenant- and scope-limited permissions.
- Observable failures and latency.
- Provider replacement without redesigning operator workflow.
- Server-side, tenant-isolated secrets.
Normalise without pretending every provider means the same thing
A shared model preserves semantics but does not invent unavailable facts. Unsupported delivery estimates remain unknown. Raw statuses may help diagnostics but should not directly drive customer-facing claims.
A safe path from context to action
- Read-only context.
- Policy-aware preview.
- Authorised confirmation.
- Idempotent connector execution.
- Audited provider result.
Checklist before integration pricing
- Which fields exist and which system owns each fact?
- How quickly does data arrive: events, polling, or manual refresh?
- What are the API limits, retry rules, and partial-failure behaviour?
- Is there a test environment and acceptance set based on real store cases?
- Who diagnoses faults across store, connector, and WMS?
- What are the permission, retention, export, and maintenance-cost terms?
Decision tools
Data responsibility matrix
Assign an owner to every fact before choosing integration technology. A helpdesk copy is working context, not a new source of truth.
| Fact | Owner | Helpdesk role |
|---|---|---|
| Conversation, assignment, SLA | Helpdesk | Owns history and workflow. |
| Payment and order | Store platform / ERP | Shows a timestamped normalised fact. |
| Picking and shipment | WMS / fulfilment | Exposes context and source state. |
| Refund or cancellation | Authorised commerce system | Previews and records a confirmed result. |
Failure tests the integration must pass
Evaluate the integration while dependencies fail. Healthy state is only one production case.
| Failure | Safe behaviour | Unsafe behaviour |
|---|---|---|
| Provider timeout | Mark data unavailable and preserve conversation workflow. | Show unaged cache as current. |
| Partial response | Identify reliable and unknown surfaces. | Treat the record as complete. |
| Action retry | Reuse idempotency key and read the result. | A second refund or cancellation. |
| No confirmation | Unknown outcome and manual verification. | Tell the customer the action completed. |
Common questions
Does Faboxi connect directly to a WMS database?
No. Commerce data flows through connectors and versioned APIs without direct Faboxi access to WMS or CMS databases.
Why start read-only?
It validates data quality and operator workflow without risking order changes during the first implementation stage.