Guide

Several people approving
one item

This is the most common approvals question in monday, and it has a clean explanation: a status column holds one value, and an approval with three approvers is a set of three answers. You cannot store a set in a single value.

Why it fights you

A column records the last click.

Not who has answered so far.

A People column answers who is this assigned to. A Status column answers what state is it in. An approval needs a third thing that neither of them stores: who has answered, and what each of them said.

With one status column and three approvers, the column can hold “Approved” — but not which of the three approved, nor that the other two have not looked. If Legal approves and then Finance rejects, the column says Rejected, and Legal’s decision is gone as though it never happened.

The native workaround

A column per approver, plus a rollup.

It works. Here is exactly what it costs.

Give each approver group its own pair of columns, and one overall status driven by automations:

Legal approver (people) · Legal status
Finance approver (people) · Finance status
Overall status
when Legal status is Approved and Finance status is Approved,
set Overall status to Approved

What it costs: two columns per approver group, an automation per combination, and a board that becomes unreadable at about three groups. Adding a fourth approver means new columns, new automations, and revisiting every rule you already wrote.

What it still will not do: “any two of these three”. That is a quorum, and a rule engine built on “A and B and C” cannot express it without one branch per combination. With three approvers that is three rules. With five it is ten.

The part people want next

And the part that is not about columns at all.

Everybody who solves the routing asks the same question a month later: when did each of them agree, and what were they looking at?

That is the question a dispute turns on. Six months after a revision goes wrong, “the drawing was attached to the item” and “the person who signed it had that version in front of them” are different claims, and only the second one settles anything. A status column cannot tell you which, because it never knew.

Questions

The ones that follow.

Can we do approvals in order rather than all at once?

Natively, yes, with a chain of automations — when Legal status becomes Approved, notify Finance. It is the same shape as the rollup and costs the same in columns. What it will not do is hold the sequence as a thing you can look at: “this is on stage two of three, waiting on either of these two people” lives in your head and in the automations, not on the board.

What about subitems, one per approver?

It works and it is tidier than columns for four or more approvers. The trade is that the approval stops being visible on the item — you have to open the subitems to see where it is — and reporting across boards gets harder, because you are now aggregating subitems rather than items.

When is the native version genuinely enough?

One or two approvers, low stakes, and nobody is ever going to dispute it afterwards. That is a lot of approvals, and if that is yours, do not add software for it. The guide on building the workflow tells you how.

What we built

Stages, quorum, and a record.

For when working around it costs more than it saves.

Signoff holds the approval as its own thing rather than as a column. Several approvers per stage, in order: everyone must agree, any one of them is enough, or two of the three — set per stage rather than once for the whole approval. No columns are added to your board unless you ask for one.

Every decision is recorded with its timestamp, its comment, and the exact file versions that were on that person’s screen — and if a file is replaced afterwards, the approval reopens and the original decision is kept as a record of what they actually saw.

Try it on one item.

Three approvals a month, free, with every feature turned on — stages, quorum, external approvers and the record.