Projects has its own automations, separate from the workspace-wide ones. They fire on things that happen to sprints and issues.
The triggers
| Trigger | Fires when |
|---|---|
| Status changed | An issue moves between columns |
| Issue assigned | Work is given to someone |
| Bug created | A new bug arrives |
| PR opened | A pull request is raised, where code is connected |
| Sprint started | A round opens |
| Sprint ended | A round closes |
| Daily digest | Once a day, on a schedule |
What they are good for
The ones that earn their keep are the small procedural ones nobody wants to own:
- Notify the tester when an issue reaches review
- Post a summary when a sprint ends
- Flag a bug raised against work that shipped this round
Sprint ended is the most useful and the most neglected. It is the natural moment to capture what happened, and the moment everyone has already moved on.
What they are not
These are rules, not judgement. They fire on the event whether or not it made sense, so a trigger on every status change will produce noise on a busy board and people will filter it out within a week.
Start with one, on the event that actually gets missed today.
Automations cost nothing to run, however often they fire. They are code, not a language model.
Did this answer your question?
No, ask a person