Posting rules: stages, quorums and the approval status field

Give a table posting rules and its records earn their way to Posted through ordered approval stages — each with its own approvers, quorum and clock — with the whole journey written through a real Select field, so views, reports and automations see approval state as an ordinary value. One policy per table A table has at most one set of posting rules, built by an Admin from Posting rules next to the field editor. On tables without one, none of this chrome exists — no panel, no approval status, nothing to learn. Add a policy and every record in the table gains a journey: Draft → each stage in order → Approved → Posted. The approval status lives in a real field Every step of the journey is written into a Select field you pick — or, if you don't pick one, a field called Approval status is created for you. The builder adds the values it needs as real options: Draft, an Awaiting … value per stage, Changes requested, Approved, Posted. This is the design decision that makes everything else free: "everything sitting with Finance" is a saved view, a board column, a report group and an automation trigger, because approval state is an ordinary field value — not a parallel system bolted on beside your data. By default the field only changes through the flow itself; see Why you can't edit the approval status field. Stages: who is asked, and how many must agree Each stage names its approvers one of three ways: picked people, a People field on the record (the account manager approves their own account's records — routing no fixed list can do), or a role (any workspace Admin). Its quorum is everyone, any one, or N of M. Within a stage, approvers are asked in parallel. Between stages the flow is strictly sequential: the next stage's people aren't asked until the previous quorum clears, so nobody ever sees an ask that might not matter. The moment a quorum is met the record advances — same instant, same transaction, no sweep to wait for. Stages that only sometimes run A stage can carry conditions on the record — Amount greater than 5000 pulls the CFO stage into the journey only when it should be there. Conditions are checked when the stage would open; a stage that doesn't match is skipped, and the skip is recorded so the trail never shows a silent gap. Submitting, and what a rejection does Submit for approval on the record opens stage one and fans out its asks. Submitting needs only view access — asking is the point. The requester can withdraw while the journey is in flight. A rejection anywhere drops the record to Changes requested, with the approver's reason attached, and edits unfreeze so the record can be fixed. What resubmitting does is the policy's choice: restart from the first stage (the record changed, so earlier approvals are stale — the safe default) or resume at the stage that said no, keeping earlier answers for long chains where a late no shouldn't re-tax early approvers. The last step: Posted When the final quorum clears and every gate is green, the record is ready to post — the people who can post are told. Who that is, is the policy's call: anyone who can edit the table, or Admins only. There is also an auto-post switch for the fully hands-off pipeline, off by default because most teams want the deliberate click. What Posted means — and how to undo it — is its own article: Posted: the seal, and unposting. One guarantee underneath all of it: what a decision means is frozen when the ask is created. Editing a stage tomorrow never rewrites a question already sitting in someone's queue today. Tips • Let the builder create Approval status for you — the default name says exactly what the field is, and the options arrive pre-wired. • Use a People field as a stage's approver for routing that follows the record — the right account manager is asked automatically, per record. • Name stages after the people, not the step number: the per-stage Awaiting Finance value is what your saved views and boards will read. • Save a view filtered to Changes requested — it is the team's fix-it queue, and it empties itself as records are resubmitted. Good to know • The approval status values must exist as options on the target Select — the builder adds missing ones itself, and the field editor refuses to delete an option a live policy writes. • Posting rules and the Lifecycle tab are separate state machines and can't govern the same Select field — pointing both at one is refused, and each builder marks a field the other already owns. • Two option values differing only by capitalisation are refused outright: they would look identical to the flow and make quorum advancement ambiguous. • A stage whose People field is empty (or names someone no longer in the workspace) parks the journey and says so on the Posting panel — fix the approvers or the field, then resubmit. • Switching a policy off keeps its history legible — past decisions still name their stages — but records already Posted stay Posted; the seal is on the record, not the policy. Who can do what • Building and changing posting rules is Admin-only. • Submitting a record for approval needs only view access. • Posting requires edit access on the table, or Admin, per the policy's "who can post" setting; unposting always requires delete-level access on top. • Approvers need no particular role — the flow writes the field, not their edit rights.