Set a workflow owner and handle failures
Every workflow has an owner, precisely so a broken automation is somebody's problem rather than nobody's.
The classic automation disaster is not a workflow doing the wrong thing. It is a workflow that quietly stopped doing the right thing, six weeks ago, and nobody noticed because nothing announced it.
The owner field exists to make that impossible. It is required, and the card states its own purpose: who gets told when this workflow fails. Choose somebody who will both notice and be able to fix it.
Steps
Set an owner on every workflow
It is required by design, and the card says what it is for.
Choose somebody who will act, not somebody senior
The owner needs to be able to open the workflow and understand it — a manager or admin who knows the process. Ownership by somebody who will forward the notification to somebody else is not ownership.
Watch the notification feed
Failures arrive there, alongside template approvals and mentions. It is the only place the product proactively tells you something is wrong.
If you own workflows and never open the feed, you have no failure detection at all — which is how an automation ends up broken for six weeks.
Diagnose by reading the three blocks
Because the definition is readable, most failures are obvious on inspection: a channel that was disconnected, a template that was rejected, an attribute somebody deleted, a stage that was renamed.
Turn it off while you fix it
Use the Live toggle rather than deleting. You keep the definition and stop the damage, and you can turn it back on when you have tested the fix.
Reassign ownership when people leave
A workflow owned by a deactivated user is a workflow whose failures go nowhere. Put this on your offboarding checklist alongside reassigning conversations.
Check it worked
Deliberately break a test workflow — point a step at a disconnected channel — and confirm the owner is told. If that notification does not arrive, none of your failure handling works.
The parts people get wrong
- Failures are per run. A workflow can succeed a hundred times and fail on the hundred and first because of one contact with missing data.
- The run count in the workflow list is a useful secondary signal: a workflow that used to run 50 times a week and now runs twice has probably broken upstream.