Automation

What a rule is

An automation rule does repetitive work for you: when something happens, if some conditions hold, then do these actions. Open More → Automation for the list; Create Rule opens the editor. A rule has a name, a description, and at least one trigger and at least one action. On the list, use Disable / Enable to switch a rule off and on without deleting it.

Triggers — when

Trigger	Fires
issue_created	a new issue is created
issue_updated	a field changes
issue_commented	a comment is added
issue_transitioned	the status changes
sprint_started	a sprint is started
scheduled	on a schedule given as a cron expression (for example 0 9 * * 1-5 for weekdays at 09:00)
manual	when you run it yourself

Conditions — if

Conditions decide whether the actions run. Combine them with AND or OR.

• jql_match — the issue matches a JQL query (the most flexible condition).
• field_equals, field_changed — a system field (summary, description, status, priority, assignee, reporter, project, issuetype, key, resolution…) has a value, or has just changed.
• issue_type_is, priority_is, status_is, assignee_is — shortcuts for the common fields.
• reporter_is_current_user, issue_is_subtask.

Actions — then

Action	Does
transition_issue	moves the issue to a status through its workflow
assign_issue	sets the assignee
add_comment	posts a comment
update_field	sets a field
set_priority	sets the priority
add_label / remove_label	edits labels
create_issue	creates another issue
link_issue	links to another issue
send_email	sends an e-mail
send_webhook	calls an external URL
log_action	writes a line to the rule’s history (useful while testing)

Testing a rule

Save the rule first (“Save the rule before testing”), enter a Test Issue Key and press Test to run the rule once against that issue. The result — success, failed or skipped — appears at once. A rule is skipped when its conditions did not match.

Execution history

Every run is recorded: when, which issue, whether it succeeded, was skipped or failed, and why. Open a rule’s history first when it “did not work”. The usual reasons are a condition that did not match, a transition the workflow does not allow, or a permission the rule’s actor lacks.

Recipes

• Assign new bugs to the component lead: trigger issue_created, condition issue_type_is Bug, action assign_issue.
• Tell the reporter when work starts: trigger issue_transitioned, condition status_is In Progress, action add_comment.
• Escalate stale work: trigger scheduled (cron 0 8 * * *), condition jql_match status = "In Progress" AND updated < -14d, action add_label stale.
• Notify a chat bot: trigger issue_transitioned, action send_webhook.

Service desks have their own automation (based on SLA and customer events); see Queues, SLA & email. Administrators can switch the whole feature off from Features and modules.