Stages vs option field vs status
Use stages when something moves through a process and you care how it progresses — they give you a board, a history of every move, and funnel numbers. Use an option field to classify something that is not a journey, like priority or type. Status is neither: it controls public visibility, not workflow.
Requirements: a role that can edit a collection's fields and its pipeline.
Three things in Sonta look similar from a distance — each holds one value from a small set — and choosing wrongly is one of the easier modelling mistakes to make. They are not interchangeable: two model your data, and one does not model anything at all.
Status is not a choice you are making
Clear this one out of the way first. Status is a built-in field on every entry with three values — draft, published, unpublished — and it decides one thing: whether the entry is publicly visible on a connected site. It is not a workflow. If you find yourself wanting to add "in review" or "approved" to it, you want stages instead. Status answers "can the public see this", never "where is this in our process".
Stages — for things that move
Reach for stages when an entry travels through a process and eventually leaves it: a deal from qualifying to won or lost, a job from booked to done, an application from received to decided. Stages live in the collection's pipeline, and they bring things an ordinary field cannot:
- A board. Entries become cards you drag from one stage to the next.
- A sense of open and closed. Each stage is categorized as open, closed, or archived, so the system knows Won and Lost both mean finished while the rest are still live — which is what makes "how much is still in play" answerable.
- History. Every move is recorded, so you can see when an entry entered a stage and how long it sat there.
- Funnel numbers. Because moves are tracked, you get conversion between stages and time spent in each — impossible to reconstruct from a plain field, which only ever shows its current value.
- Forecasting. Stages can carry a likelihood of closing and a forecast category, which is how a pipeline produces a projection rather than just a list.
An option field — for things that simply are
Reach for an option field when the value classifies an entry rather than tracking its journey. Priority: low, medium, high. Deal type: new business, renewal, expansion. Loss reason: price, timing, competitor. These change occasionally, but they are not a path with a beginning and an end, and nobody wants a board of them or a conversion rate between them.
The test that settles most cases: does an entry travel through these values in a roughly predictable direction, and does it matter how long it took? Yes to both — stages. No — an option field.
What each costs
- Stages are heavier. They belong to the collection's pipeline and carry rules — finishing stages must be marked closed, names and colors do not repeat. That structure is what buys you the analytics, but it is more than a field.
- Only one journey per collection. Stages model the process an entry is in. If you need a second independent progression on the same entry, that is an option field alongside the stages, not a second set of stages.
- An option field forgets. It holds only its current value — no history, no time-in-state, no conversion. If you later want to know how long something sat in "pending", a field cannot tell you retroactively.
- Status cannot be extended. Its three values are fixed; it is not a place to record workflow.
Rule of thumb
A journey with an end, where progress and timing matter — stages. A label that describes the entry — an option field. Public visibility — status, and nothing else.
Related
How stages fit the wider model is in the data model; field types and their settings in working with collections and fields. Boards built on stages are covered in views and record layouts, and stage-based reporting in how reports work.