Automations
Automations are the rules that chase things so a person does not have to: a ticket goes blocked and someone is told, a critical ticket sits unassigned and someone is told, a sprint's velocity drops and someone is told. You define the rule once; it fires every time.
Where: Settings › Automations You need: project admin rights
When to use this, and when not to
| You want | Use |
|---|---|
| To be told when something happens, repeatedly | An automation |
| To be told about one ticket | Watch it — see Notifications |
| Someone to actually decide something | A person. Automations chase; they do not judge |
| Analysis of what keeps going wrong | Sprint Insights |
An automation surfaces a fact. It cannot unblock a ticket, reassign work, or decide whether a slipping sprint matters — so build them to reach the person who can.
The page
Rules are grouped by category, each with an active/off toggle and a count of how often it triggered this week. The header keeps score — how many are active, how many are off.
Those trigger counts are the most useful thing on the page. A rule that never fires is either working as a deterrent or watching for something impossible; a rule firing constantly is training people to ignore it. Both need attention.
Building a rule
New Automation walks through three parts.
1. The trigger — what starts the rule:
- A new ticket is created, or tickets are added to the active sprint
- A ticket's status changes, or it enters Blocked
- A ticket becomes overdue, or its due date approaches
- A ticket has no activity for X days
- A critical ticket has no assignee
- A team member is @mentioned with no response after a set time
- A team member has zero activity
- Sprint end approaches, or sprint velocity drops below a threshold
2. The conditions — narrow it: only certain priorities (Critical or Major), only the active sprint, only after a duration, or below a threshold. Some triggers need no extra configuration.
3. The action — who gets told: the assignee, all assignees, the manager, or the project owner.
Three rules that earn their keep
- Blocked → notify the manager. Blocked tickets are the sprint's silent killer; this makes them loud.
- Critical with no assignee → notify the project owner. A critical ticket nobody owns is a contradiction.
- No activity for 5 days → notify the assignee. Politely returns wandering tickets to memory.
Start with these three, run them for a month, then add more only where you can name the problem the rule solves.
What Happens Next
- The rule fires on every matching event from the moment it is active — it does not act on history.
- Notifications reach recipients through their notification preferences, so someone who has switched off a channel will not see it there.
- The trigger count updates weekly, which is how you tell a working rule from a dormant one.
Tips
- Notification fatigue is real and it is permanent. Every rule that fires teaches people either to read it or to ignore it — and once a team learns to ignore automated messages, the useful ones stop working too. Few rules, tuned thresholds, and a willingness to switch off a noisy one.
- Send to the person who can act. Notifying the assignee that their ticket is blocked tells them what they already know. Notify whoever can unblock it.
- Review the trigger counts monthly. It takes two minutes and it is the only feedback loop this feature has.
- Turn a rule off rather than tolerating it. A rule everyone ignores is worse than no rule, because it looks like coverage.
Troubleshooting / FAQ
Q: A rule shows zero triggers. Either the condition never matches, or it is too narrow. Check it against a case you know should have fired.
Q: People say they are not getting the notifications. Check their notification preferences — a rule can fire correctly and still be muted at the recipient's end.
Q: We are drowning in automated messages. Turn rules off until the remaining ones are read. Adding conditions to narrow a noisy rule is the second move; switching it off is the first.