Statuses, steps and priorities¶
These lists drive how work moves through the pipeline and how it reads at a glance. They live in Settings → Workflow and apply consistently across every view, chart, and API response.
Statuses¶
A status is a named state a record can be in. Each status carries:
- a code (camelCase, stored on every record),
- a display name and short name (the badge abbreviation),
- a colour and icon,
- a state — the normalised lifecycle value the app uses for aggregations, sorting, and rollup logic,
- behaviour flags —
is_done,is_wip,is_retake,is_feedback.
Built-in statuses¶
| Code | Name | Short | State | Flags |
|---|---|---|---|---|
waitingToStart |
Waiting to Start | WTG | not_started |
— |
inProgress |
In Progress | IP | in_progress |
is_wip |
pendingReview |
Pending Review | REV | in_progress |
is_feedback |
final |
Final | FIN | done |
is_done |
omitted |
Omitted | OMT | cancelled |
is_done |
onHold |
On Hold | HLD | blocked |
— |
active |
Active | ACT | in_progress |
is_wip — Project only |
archived |
Archived | ARC | done |
is_done — Project only |
The five state values are: not_started, in_progress, blocked, done,
cancelled. They are used by reports, Gantt colouring, and automation rollup
rules.
Statuses are global; scoping is per schema
The status list is shared across all entity types. Which statuses appear for each type inside a project is controlled by the workflow schema.
Transitions¶
Settings → Workflow → Transitions defines the legal moves between statuses for each entity type. The default Task workflow is:
waitingToStart→inProgressinProgress→pendingReview,onHold,omittedpendingReview→inProgress,finalonHold→inProgresswaitingToStart→omitted
Project statuses transition between active, onHold, and archived.
Transition rules are enforced by the API regardless of which client requests the change. The UI's status picker only shows legal next states.
Steps¶
Steps are the pipeline/department stages a Task belongs to. Each step has a camelCase code, display name, colour, icon, and sort order.
Built-in steps¶
| Code | Name | Colour |
|---|---|---|
concept |
Concept | Yellow |
model |
Modeling | Cyan |
rig |
Rigging | Purple |
lookDev |
Lookdev | Teal |
layout |
Layout | Fuchsia |
anim |
Animation | Pink |
fx |
FX | Amber |
light |
Lighting | Green |
comp |
Compositing | Blue |
matchMove |
Matchmove | Sky |
roto |
Roto | Rose |
Which steps are available inside a project depends on the workflow schema's
types.Task list. Steps are rendered as coloured chips wherever tasks appear.
Priorities¶
Priorities carry a code, display name, colour, icon, and a numeric value used for sorting and reporting.
| Code | Name | Value |
|---|---|---|
none |
None | 0 |
low |
Low | 10 |
medium |
Medium | 20 |
high |
High | 30 |
urgent |
Urgent | 40 |
Priorities apply to Tasks, Shots, and Versions (all stored as a text field
with a priority widget, resolved via the priority table at render time).
Asset types¶
The asset type list (Character, Creature, Environment, Set, Prop, Vehicle,
Weapon, FX, Crowd, Matte Painting by default) is a configurable enum stored on
the Asset.asset_type field. Which asset types are available in a project is
controlled by the workflow schema's types.Asset list.
Product types¶
Product types (Animation, Audio, Camera, Compositing, Edit, FX, Geometry,
Hair, Image Sequence, Light Rig, Render, Rig, Scene, Script, Upload) are a
similar configurable enum on the Product.product_type field. They are not
scoped per schema — all types are available in every project.
Idempotent seed
The server adds any missing statuses, steps, and priorities on every start but never overwrites existing configuration, so your colour and icon customisations survive restarts.