The short answer
An automation set to fire “when a mirror column changes” usually won’t run on the board that shows the mirror. A mirror is a read-only window into another board’s item, so the change event that automations listen for happens on the source board, where the real column lives — not on the board displaying it. You’re not misconfiguring the recipe; the trigger has nothing to hear. monday.com has piloted partial mirror handling in a few 2026 automation recipes, but there is still no general native “when this mirrored value changes” trigger, so plan around it rather than fighting it.Why it happens
Mirrored values belong to the source item (see mirror column limitations). Automations trigger on events, and the change event is emitted where the value actually changed — on the source board. The mirror just re-renders. So a recipe watching the mirror side never receives an event to act on, which is why it looks like the automation is broken when it’s simply listening in the wrong place.What to do instead
1. Build the automation on the source board
The simplest fix: put the recipe where the real column lives. “When Status changes to Done, notify…” fires reliably on the source board because that’s where the event originates. Move the logic to the source, not the mirror.2. Copy the mirrored value into a real column, then trigger on that
If the workflow has to run on the board that holds the mirror, first land the value in a real, native column on that board — a copy-column automation or a formula column that resolves the mirror — then trigger off the real column. It’s an extra moving part to maintain, but the trigger now has a genuine event to fire on.3. Use a marketplace mirror-automation app
Apps such as Column to Column and LeanyLabs Mirror Column Automations exist specifically to bridge mirrored values into triggerable actions. They work, and they’re the honest answer when you need automation on a mirror and can’t restructure the boards.The structural fix: don’t mirror — share the item
Every workaround above exists because the data lives on only one board and the other board is looking at a copy of the view. If the workflow genuinely needs to run on both boards, the item should live on both boards. With Same Item Multiple Boards, the shared item’s columns are real native columns on every board it’s on — so automations trigger natively on either board, with no mirror in the path:- “When Status changes” fires on any board the item lives on, because it’s the same item’s real column (supported column types).
- No copy-column relays to maintain, and nothing to reconcile later (why copies drift).
- Updates and comments stay one shared thread.