Open any mature Monday board and look at a parent item marked green. Now expand it. Eight subitems done, two still open — and one of those two is the QA pass that nothing ships without, assigned to someone who's out until Thursday. The parent says Working on it in cheerful orange, or worse, someone set it to On Track three weeks ago and never touched it again. The board is not lying maliciously. It's lying structurally, because the parent status is a single field that a human sets manually and a machine can only roll up mechanically — and neither of those produces an honest answer.
This is the highest-frequency failure in Monday specifically, and it matters more than it looks. The parent row is what feeds your dashboards, your filtered views, your executive summary widget, and the conversation you have with your sponsor on Thursday. Every one of those inherits the parent's colour. When the parent lies, everything downstream of it lies with the same confidence, and the people reading it have no idea they're looking at a number that nobody actually verified against reality.
This tutorial builds an automation that watches subitem changes, reads the whole subitem set the way a sharp PM would, forms an actual judgment about the state of the parent, and writes that judgment back to Monday — both as a status colour your dashboards can use and as a plain-English sentence a human can read. Make.com does the wiring. Claude does the part that is genuinely judgment and not arithmetic.
Let Claude read all the subitems and decide what the parent status should honestly say — then write that judgment back to Monday as both a status and a sentence.
Two outputs, deliberately. The status colour is for machines — dashboards, filters, groupings. The sentence is for humans. Almost every failed version of this build produces only the first.
Monday has native automations for parent/subitem status. They look like:
When all subitems have status Done, set parent status to Done.When a subitem status changes to Stuck, set parent status to Stuck.
These are useful and you should keep using them for simple boards. But notice what they are: mechanical quantifiers. All, any, none. They can count, and that's the ceiling. Three specific things they cannot do, and each one is a way boards routinely lie:
They can't weight. All subitems done and any subitem stuck both treat every subitem as equal. But subitems are never equal. "Update the README" and "Get security sign-off" are not the same object, and a rule that counts them identically produces a parent status that is technically correct and practically worthless. Eight of ten done reads as 80% and green — even when the two remaining are the only two that could sink the release.
They can't sequence. Two subitems left could mean two independent tasks that run in parallel and finish Tuesday, or a chain where B can't start until A ends and A is blocked. Identical counts, opposite realities. Nothing in a native automation can see the difference.
They can't explain. A rule sets a colour. It cannot write "on track overall, but QA sign-off is the real risk — it hasn't started and it's the only thing between us and ship." And the explanation is most of the value, because a colour tells you that something is wrong while a sentence tells you what to do about it.
There's also the manual case, which is worse than the mechanical one: on most boards the parent status is just set by hand and then quietly rots. It reflects what someone believed at the moment they last thought about it. Percentage-done columns have the same flaw wearing a more numerical disguise — a progress bar is just counting with better graphics.
So the gap is specific and narrow: weighing unequal things and explaining the result. That's a judgment task, which is exactly the seam where an LLM belongs and where a rules engine has never been able to reach.