How do I route an approval to the person named in a People column in monday.com?

monday.com cannot natively route an approval to whoever is named in a People column on the item. The assign and notify automations bind specific people at the moment you build the recipe, so the approver is fixed in the configuration rather than read from the item at run time. If the approver changes per request, per department, or per amount, you are hard-coding one recipe per approver or pushing the routing out to an external tool.

There is a second half to this that gets noticed later, usually during an audit. Being notified and being the only person who can decide are different things, and monday's native pieces give you the first one.

What monday can and cannot do here

Start with what works, because the limitation is easy to overstate. A Status column standing in for the approval state, plus a recipe along the lines of "when status changes to Waiting for approval, notify someone", covers a real and common case. If the person signing off is always the same person, this is a perfectly good setup and you do not need anything else.

The wall appears when the approver is not always the same person. The people picker inside a recipe holds the users you selected. It has no mode where you hand it a column and say "whoever is in here." Users hit this constantly at the intake step, where a form submission carries the intended approver and the automation cannot use it.

Source: monday community, how can I use an automation to take someone from a people column ("the stock automation for assign/re-assign can only choose specific people in my company, not the people column from the form submission").

Why this specific gap exists

A monday recipe is configured once and then runs many times. When you pick people while building it, what gets stored is those users, not an instruction to go and look somewhere on the item. Item data flows into the trigger side of a recipe. It does not flow into the slot where the recipient was chosen.

The enforcement half has the same shape. Limiting who may edit a column natively means naming those people in the configuration, which lands you back at a fixed list rather than a rule that follows the item. There is an open feature request asking for exactly this, permissions that track a People column, which is a reasonable signal that it is not available today.

Source: monday community feature request, more flexibility with view and edit column permissions.

What people try, and where each one breaks

Approach	What it does	Where it breaks
One notify or assign recipe per approver	Routes correctly for a known, fixed set of people	Every new approver, department, or region is another recipe. The board accumulates them and nobody maintains them
Status column plus a board-wide notification	Everyone can see what is waiting	Anyone with edit rights can set it to Approved, and afterwards there is no record of who was supposed to decide
A chain of status columns, one per stage	Models a genuine multi-stage sign-off such as operations, then finance, then management	Each stage still hard-codes its own approver, so the maintenance problem multiplies by the number of stages
Make or Zapier	Can read the People column at run time, which is the thing monday will not do	An external system, an extra bill, another place to debug, and the decision still lands in a status column anyone can edit
Form plus assign automation	Captures the intended approver at intake	The automation cannot use the value the form just captured, which is the original complaint above

The multi-stage case is worth calling out because it looks like the most professional setup and is the one that ages worst. Wiring operations, finance, management, and a final sign-off as separate columns with separate recipes works on the day you build it, and every subsequent personnel change costs you an edit in several places.

A workaround you can set up today

If your approvers are a small, stable set and you need something now:

1. Add a Status column for the approval state, with Pending, Approved, Rejected, and Changes requested.
2. Add a People column named Approver and populate it per item. It will not drive the automation, but it records the intent, and it is what you will search on later.
3. Build one notify recipe per approver, triggered on the status moving to Pending.
4. Add an automation that writes status changes into the item's Updates, so there is at least a human-readable trail.

Be clear-eyed about what this is. The People column is documentation, not routing. The trail in Updates is a convenience, not an audit record, because the status itself remains editable by anyone with board rights. For a small team where everyone knows who signs off, that is usually an acceptable trade.

What a real fix looks like

If the routing and the enforcement are both blocking you, the shape of a proper solution is specific. It reads the approver from the People column on the item at the moment sign-off is requested, so no recipe has to be maintained per person. Then it checks that decision on the server, so that the only decision that counts is the one from the person who was named, and a value posted from a browser cannot overrule it.

Two more properties matter for anything that will be audited:

• Approved has to stay approved. If there is a path back out of the approved state that leaves no mark, then the state is a label rather than a control.
• The trail has to be append only. An undo should be recorded as a further event rather than erasing what happened, otherwise the record cannot answer the only question an auditor asks, which is who decided what and when.

One honest boundary, because these get bundled together in conversation and they are not the same job. Routing to a named approver, delegation when that person is away, escalation after a request goes stale, quorum or parallel approval where several people must sign, and delegation of authority routing by amount are five distinct problems. A tool that solves the first one well has not automatically solved the other four, and it is worth asking which of them you actually have before scoping anything.

The short version

monday can notify a fixed approver reliably, and for a lot of teams that is the entire requirement. What it does not do natively is take the approver from a People column on the item, or make an approval something that only the named person can grant and that cannot quietly be changed afterwards. Those two gaps are structural rather than a setting you have missed, which is why the workarounds all end up either hard-coding people or leaving monday for an external tool.