Configurable Status Workflows
Statuses are data the admin defines, not values baked into code, because every business runs its operations differently and each product type has its…
Why are statuses data-driven instead of hard-coded?
Statuses are data the admin defines, not values baked into code, because every business runs its operations differently and each product type has its own natural lifecycle.
How does an admin create, rename, reorder, and recolor statuses per product type?
From the admin (Catalogue → Status Workflows), an admin manages a list of statuses per product type.
What are the initial/terminal status markers?
Each status can be flagged as initial (the starting state a new item enters) or terminal (an end state, like Delivered or Cancelled).
How do status changes drive notifications and KPIs?
Status is the engine of automation.
How is every status change recorded for audit and KPI purposes?
Every status change on a fulfilment is recorded in a status history (FulfilmentStatusHistory) — capturing the transition (from → to), who changed it, when, and an optional note.
Can a new status be added to a live product type at any time? What happens immediately?
Yes — an admin can add a new status to a live product type at any time, and it becomes available immediately in that type's workflow.
Give an example status lifecycle for Physical vs Service products.
The two types naturally differ.