Order Lifecycle

The Big Picture

Every order in Omnium follows a lifecycle: it is created, processed through a series of statuses, and eventually completed, canceled, or returned. At each status transition, workflow steps execute automatically — reserving inventory, capturing payment, sending notifications, exporting to ERP, and more.

This page gives you the full picture of how orders move through the system. For API reference, see Order API. For configuration details, see Order Configuration.

Key Concepts

Order Types

Order types define the kind of transaction. Each type has its own status flow and workflow configuration.

Each order type is configured independently in Configuration > Order Types in the Omnium GUI. You can create custom order types, copy existing ones as templates, and configure completely different workflows for each.

Lifecycle Stages

An order moves through these stages, regardless of order type. Not every order passes through every stage — a POS order may skip allocation entirely, while an online order goes through the full flow.

Stage 1: Creation

An order is created either from a cart (checkout flow) or directly via the API.

Cart → CreateOrderFromCart → Order (Status: New)

Or directly:

POST /api/orders → Order (Status: New)

When an order is created, the system:

• Assigns an order number (auto-generated or explicit)
• Sets the initial status to New (or the first status in the order type)
• Triggers all workflow steps configured for that status

Stage 2: Validation and Enrichment

Workflow steps at the New status typically handle:

• Enrichment — Populating order data from product catalog (prices, names, images, tax rates)
• Validation — Checking for fraud, verifying inventory, validating serial numbers
• Customer — Creating or linking the customer record
• Tagging — Adding tags based on order properties (payment type, category, etc.)
• External IDs — Generating or setting external reference numbers

Stage 3: Allocation

The system decides which warehouse fulfills each item:

• AllocateToWarehouse — Assigns items to a specific warehouse
• SetWarehouseBasedOnZip — Picks the closest warehouse by postal code
• TryReallocateEntireOrder — Moves items if the assigned warehouse is out of stock
• SplitAllLineItems — Splits the order into multiple shipments when items come from different warehouses

After allocation, inventory is typically reserved:

• IncreaseReservedInventory — Marks stock as reserved so it's not oversold

Stage 4: Payment

Payment handling depends on the payment provider and business rules:

• AuthorizePayment — Authorizes the payment (holds funds)
• VerifyOrderPaymentMethod — Confirms the payment method is valid
• SetAuthorizationExpires — Sets a deadline for payment capture
• CheckAndUpdateCouponUsage — Tracks coupon/voucher usage

Stage 5: Fulfillment

The order moves through packing and preparation:

Workflow steps at these stages typically:

• Print shipping labels (PrintShippingLabel)
• Create shipment bookings with carriers (CompleteShipment)
• Validate tracking numbers (ValidateTrackingNumber)
• Export to ERP (ExportOrder)

Stage 6: Shipment and Payment Capture

When the order ships:

Workflow steps at shipment typically:

• CapturePayments — Captures the authorized payment (charges the customer)
• ReduceInventory — Decrements physical stock levels
• UpdateShipmentStatus — Syncs shipment status with carrier
• Notification — Sends shipping confirmation to customer
• ExportOrder — Sends shipment data to ERP

Stage 7: Completion

Workflow steps:

• SetCompletedDate — Records the completion timestamp
• AnalyticsIndexing — Updates analytics data
• Customer Club Points — Awards loyalty points (if customer club is configured)

Stage 8: Returns (Optional)

If the customer returns items, a return order is created:

Order (Completed) → Create Return → Return Order (with return workflow)

Return workflows handle:

• EnsureRma — Generates a return merchandise authorization number
• CreditReturn — Processes the refund
• UpdateInventory — Returns items to stock
• CreateCreditNote — Generates a credit note
• Notification — Sends return confirmation

See Returns for the complete returns documentation.

Common Order Flows

Online Order — Happy Path

New
 │  EnrichOrderFromProducts
 │  IncreaseReservedInventory
 │  AuthorizePayment
 │  GetOrCreateCustomerFromOrder
 │  Notification (order confirmation)
 ▼
InProgress
 │  AllocateToWarehouse
 │  ExportOrder (to ERP)
 ▼
PackedAndReady
 │  PrintShippingLabel
 │  CompleteShipment
 │  ValidateTrackingNumber
 ▼
Ship
 │  CapturePayments
 │  ReduceInventory
 │  Notification (shipping confirmation)
 │  ExportOrder (shipment update to ERP)
 ▼
Completed
    SetCompletedDate
    AnalyticsIndexing

Click and Collect

New
 │  EnrichOrderFromProducts
 │  IncreaseReservedInventory
 │  AddClickAndCollectTags
 │  Notification (order received)
 ▼
InProgress
 │  AllocateToWarehouse (store location)
 ▼
ReadyForPickup
 │  SetReadyForPickupDate
 │  Notification (ready for pickup)
 ▼
PickedUp
 │  CapturePayments
 │  ReduceInventory
 │  SetCompletedDate
 ▼
Completed

If the customer doesn't collect the order within the configured deadline, the order automatically transitions to NotCollected and triggers cancellation workflows. See Click and Collect for details.

Split Shipment

When items ship from different warehouses, the order is split into multiple shipments:

New → InProgress
 │
 │  TryReallocateEntireOrder
 │  SplitAllLineItems (creates Shipment A + Shipment B)
 │
 ├─ Shipment A (oslo-warehouse)
 │   Ship → InTransit → Completed
 │
 └─ Shipment B (bergen-warehouse)
     Ship → InTransit → Completed

The main order status reflects the overall state:

• PartiallyShipped — Some shipments sent, others pending
• Completed — All shipments delivered

Cancellation

An order can be canceled from most statuses:

Any Status → OrderCanceled / OrderCanceledByCustomer / OrderCanceledByStore
                │
                │  CancelPayments (releases authorization)
                │  TryReallocateOnCancel (frees reserved inventory)
                │  SetCanceledDate
                │  Notification (cancellation confirmation)
                │  ExportOrder (cancellation to ERP)

Order Statuses Reference

These are the built-in statuses available in Omnium. Not all statuses need to be used — you configure which ones apply to each order type.

Processing Statuses

Fulfillment Statuses

Shipping Statuses

Completion Statuses

Cancellation Statuses

Return Statuses

Other

Shipment Statuses

Each shipment within an order has its own status, independent of the order status:

Order statuses can be configured to automatically sync with shipment statuses. For example, when an order moves to "Ship", all its shipments can automatically update to "Shipped".

How Workflows Work

When an order transitions to a new status, the system executes all workflow steps configured for that status. Steps run sequentially, and each step can modify the order, call external systems, or trigger further status changes.

Workflow Step Properties

Scope Filters

Each step can be restricted to run only for specific contexts:

Conditions

Steps can have conditions based on previous step results:

This lets you build error-handling flows: for example, send an alert notification only when the ERP export step fails.

Synchronous vs. Asynchronous

• RunAfterOrderIsSaved = false (default): Step runs immediately during the status transition. The API call doesn't return until all synchronous steps complete.
• RunAfterOrderIsSaved = true: Step runs in the background after the order is saved. Use this for operations that don't need to block the response — like ERP exports, analytics indexing, or heavy integrations.

Workflow Groups

Multiple steps can be bundled into reusable groups. A group is referenced by a single workflow step using the GroupId property. All steps in the group execute sequentially, and the group's StopOnError flag controls whether a failure aborts the remaining group steps.

Groups are useful when the same set of steps (e.g., "ERP export + notification + analytics") is used across multiple statuses or order types.

For the full list of available workflow steps, see Workflow Steps Reference.

Configuring Your Own Workflow

Prerequisites

Before orders can flow through the system, you need:

1. Markets and Stores configured (Markets, Stores)
2. Products with inventory (Product, Inventory)
3. Payment provider set up (Payments)
4. Shipping provider set up (Shipments)

Setting Up an Order Type

1. Navigate to Configuration > Order Types in the Omnium GUI
2. Create a new order type or copy an existing one as a template
3. Define the statuses your orders will use (you don't need all 30+ statuses — most workflows use 4–8)
4. For each status, add workflow steps that should execute
5. Set the Order value on each status to define the sequence (lower numbers run first)

Workflow Chart

The Workflow Chart in the GUI provides a visual editor:

• Statuses appear as columns ordered by their Order value
• Workflow steps appear as boxes within each status column
• Connections between steps and statuses show the transition flow
• Right-click a status to edit its properties
• Click "Edit Workflow Steps" to add, remove, or reorder steps

Tips

• Start simple: Begin with 4–5 statuses (New, InProgress, Ship, Completed, Canceled) and add more as needed
• Test with dry-run: Use the workflow test mode to validate your configuration before going live
• Use tags for branching: Rather than creating many order types, use order tags with EnabledForTags/DisabledForTags on workflow steps to handle variations within a single order type
• Mind the order: Steps run top-to-bottom. Put validation before enrichment, enrichment before allocation, and allocation before payment
• Use RunAfterOrderIsSaved for non-critical steps like analytics, notifications, and ERP exports to keep the checkout fast

Where to Go Next