Jira Automation, Notifications, and Event-Driven Behavior
Automation building blocks
Jira automation rules consist of a trigger (what starts the rule), optional conditions (should it continue?), and actions (what it does). Triggers include issue created, transitioned, field changed, scheduled, and incoming webhook. Conditions include JQL checks, user checks, and field comparisons. Actions include editing fields, transitioning issues, assigning, commenting, and sending notifications.
Notifications are governed by the notification scheme, which maps events (issue created, updated, commented) to recipients (current assignee, reporter, groups, roles). Automation can send its own notifications independent of the scheme, which is a common source of duplicate emails. Events are the underlying mechanism; workflows fire events via post functions, and notification schemes listen for them.
Traps to watch
- Forgetting that a rule must be enabled and that its scope (global vs. project) affects which issues it can act on.
- Assuming automation respects the same permission model as a human user; rules can act with elevated scope, which surprises candidates.
- Confusing a rule condition (stops the rule silently) with a validator on a transition.
- Overlooking notification scheme recipients when users report missing or duplicate emails.
Rule of thumb
Read a rule top to bottom: trigger, then each condition, then each action in order. If a rule "does nothing," verify the trigger fired, the conditions passed, and the rule is enabled and in scope.
Worked example: users get two emails when an issue is commented on. One comes from the notification scheme, the other from an automation rule that also notifies. Remove one source rather than editing both blindly.