Data model

The four tables that hold per-merchant operational state. This is the public view; the columns we'll discuss in support tickets and the ones that show up in the CSV export.

Splits

One row per mixed-cart Shopify order that nohold processed. The everything we know about this split record. Surface fields:

• Identifiers for the Shopify order (numeric id plus customer-facing order number).
• Lifecycle status: pending → split → dispatched → cancelled.
• Timestamps for split, dispatch, and any cancellation request.
• Value of the in-stock half plus currency.
• The current expected ship date for the preorder half (Growth+).
• Payment-status snapshot from Shopify (Scale).
• Running refund total (Growth+).
• Captured campaign tag (Scale).
• The Brightpearl Sales Order ids for both child SOs (in-stock and preorder), once created.

These fields are also what the CSV export exposes; see Analytics → CSV export.

Dispatch queue

Each split has two outbound dispatches (one for the in-stock half, one for the preorder half) each tracked through a small state machine from queued through to done (or, after exhausted retries, dead). When both reach done, the parent split flips to dispatched.

Fulfillment holds

One row per Shopify fulfillment order that nohold placed a hold on. Tracks what variants the hold covers, the Shopify location it was assigned to (for multi-location release filtering), and its lifecycle (held → released, with the reason for the release).

Notification log

One row per customer notification attempt: whether it ended up sent, skipped (for example, notifications disabled, plan below Growth), failed (provider error), bounced, or marked as spam. Used as the source of truth for did the customer get told? and as the primary defense against double-sending.

Sends are deduped at the application layer using a per-event unique key, so the same logical notification can never be sent twice even when the underlying dispatch retries. See Idempotency.

What's not here

• Per-merchant configuration (preorder tag, ETA default, release rule, campaign-tag prefix, and so on) is stored separately from the per-order operational tables.
• Shopify and Brightpearl auth credentials are stored encrypted at rest and are never visible to other merchants or in operational queries.
• Internal webhook delivery state and audit logs are operational, not reporting; they aren't surfaced to merchants.