Record lifecycle: the states a record moves through

Give a table a state machine — which states exist, which moves between them are legal, what each state requires or locks, and what each state MEANS — written through an ordinary Select field, so every view, board, report and automation reads the state as a normal value. Opt in, one table at a time A lifecycle is added from the Lifecycle tab beside the field editor, the same place posting rules live — and it starts from the status field the table already has. The field's own options become the stages, listed with live record counts and a guessed meaning each; nothing is added to the dropdown, nothing is renamed, and no record changes. A sensible starting set of moves is generated from the meanings (step forward or back, cancel from anywhere, finish from the last stage, reopen after a failure), and every one of them is an editable checkbox afterwards. Templates exist only for a table with no usable status field: they fill an empty Select — or add a fresh Status field for you — with their own stages. A field that already has options is never templated, so a template can't bolt its vocabulary onto a dropdown people already use. Tables without a lifecycle behave exactly as they always have. Switching one off later keeps history legible rather than erasing it: past entries still name the states they moved through, because history references states by name. The state is an ordinary field A record's state is the value of a Select field you nominate — there is no hidden parallel status living somewhere else. This is the same decision posting rules made, for the same reason: "everything sitting in Qualified" is a board column, a saved view, a filter, a rollup and an automation trigger the moment it is an ordinary field value. Every state you define must exist as an option on that field. The editor creates the missing ones, and the field editor then refuses to delete an option a live lifecycle uses. The reverse can also happen: live records holding a value that isn't a stage — set before the lifecycle existed, or an option you chose to leave out. The editor lists them under Outside the lifecycle with live counts: bring a value in with one click, or open its records from the count and move them. Until then those records are exempt from every rule, and the page says so rather than leaving them silently unconstrained. Records with a blank status are reported the same way. Legal moves, and what each state demands This is the part a plain Select cannot do. For each state you set: • Which states it may move to. A move you haven't allowed is refused when someone tries it, rather than quietly recorded. • Required fields — what must be filled in before a record is allowed to arrive here. • Locked fields — what stops being editable once it does. • Whether a record in this state may be deleted. What a state MEANS Every state is mapped to one of four categories: Initial (not yet committed), Active (committed and running), Terminal · success (ended, having achieved its purpose) and Terminal · failure (ended without it). That mapping is what lets reporting — and anything built later — reason about a state set it has never seen. A workshop's Issued, a sales team's Qualified and a claims desk's Under review are all Active, so "show me what's still running" is answerable without teaching each feature your vocabulary. Tips • Name states the way your team already says them — the state value is what your boards and saved views will be captioned with. • Map states to categories honestly: a Cancelled that you mark Terminal · success will quietly flatter every report that counts outcomes. • Every record count on the editor is a link to the grid filtered to that stage — the fastest way to see exactly which records a rule will bite. • Pair a lifecycle with a numbering sequence set to allocate on transition, so drafts that never go anywhere don't burn identifiers. Good to know • Every state key has to exist as an option on the target Select. The editor adds missing ones for you; deleting one by hand afterwards is refused while the lifecycle is live. • Required and locked fields are evaluated on ARRIVAL at a state — a field locked in a later state stays editable until the record gets there. • A lifecycle and a posting policy are separate state machines and cannot govern the same Select field — pointing both at one is refused from either builder, and each picker marks a field the other already owns. They answer different questions: where a record is in its life, versus who has to say yes before it is final. A table can have both, on different fields. Who can do what • Building and changing a lifecycle is Admin-only; members are redirected to the grid. • Moving a record between states needs ordinary edit access on the table — the lifecycle constrains which moves are legal, it does not grant the right to make them.