Why a Board Move Only Fires an Automation Event When It Crosses Columns
Moving a task fires an automation event only when it crosses from one column to another — reordering cards within the same column triggers nothing.
If you're building a workflow trigger off task status changes, there's one mechanic worth knowing exactly, so your automation doesn't fire when you don't expect it to — or fail to fire when you do.
The rule
Moving a task in Tasks only emits an automation event when that move crosses from one column into a different one. Dragging a card to a new position within the same column — reordering your "In Progress" list, say — doesn't fire anything. Only a move that actually changes the task's status column does.
How it's implemented
Under the hood, a move request checks whether the column actually changed before it emits a tasks.task.status_changed event. That event is written using the same outbox pattern as the underlying database write, so the event and the move are recorded together — no separate step that could get missed.
Why this is worth stating plainly
Every automation platform accumulates the same category of confusion sooner or later: "I moved the card, why didn't my automation run." Usually the answer is a subtlety like this one. We'd rather explain the rule up front than have you debug it after the fact — if you're wiring a workflow to react to a task's status, expect it to fire exactly on cross-column moves, and only those.
If your automation needs to react to any reordering, including within a column, that's a different signal than this event currently provides — worth knowing before you build around it.