Jira Automation: How to Create Rules Without Code

How a rule works

Jira Automation lets you describe routine actions as rules instead of doing them by hand. Every rule has the same structure:

• Trigger — the event that starts the rule: an issue is created, its status changes, a field is edited, a schedule fires.
• Condition — a filter that decides whether to continue: issue type, priority, component, a JQL query.
• Action — what to do: assign, transition, edit a field, comment, send a message.

Rules are built in a visual editor: Project settings → Automation (or the global automation settings for rules across several projects). Start from the template library: many typical scenarios are already there and only need adjusting.

Triggers, conditions and actions in practice

Two more building blocks matter:

• Branches (For related issues) run actions on other issues: the parent, sub-tasks, linked issues or issues found by JQL.
• Scheduled trigger with JQL processes issues that match a query, for example everything stuck in review.

Smart values

Smart values are placeholders in double curly braces that Jira replaces with real data when the rule runs. They work in comments, emails, messages and field values.

{{issue.key}}                    PROJ-123
{{issue.summary}}                issue title
{{issue.status.name}}            current status
{{issue.assignee.displayName}}   assignee name
{{issue.priority.name}}          priority
{{initiator.displayName}}        who triggered the rule
{{issue.url}}                    link to the issue
{{now.plusBusinessDays(2)}}      date two working days from now

If a value comes out empty, check the audit log: the field may be empty or named differently in your project. Custom fields are referenced by name or ID.

Ready-made rules

Auto-assigning by component

• Trigger: Issue created.
• Condition: Issue fields condition, Component equals "Payments".
• Action: Assign issue. Choose a specific person or a list of people with round-robin or balanced workload distribution.

Instead of several similar rules, use an If/else block: one branch per component.

Closing the parent when all sub-tasks are done

• Trigger: Issue transitioned to Done.
• Condition: Issue type is Sub-task.
• Branch: For parent.
  • Condition: Related issues condition, all sub-tasks match status = Done.
  • Action: Transition issue to Done.

The same pattern works for epics and their child issues; use the matching branch.

Slack notification about critical bugs

• Trigger: Issue created.
• Condition: Issue type is Bug and Priority is Highest.
• Action: Send Slack message via an incoming webhook to the team channel.

New critical bug {{issue.key}}: {{issue.summary}}
Reporter: {{issue.reporter.displayName}}
{{issue.url}}

Reminder about stale reviews

• Trigger: Scheduled, every weekday morning, with JQL status = "In Review" AND updated <= -2d.
• Action: Comment on issue mentioning the assignee, or one Slack message with the list.

Execution limits and good practice

Automation is not unlimited:

• Execution quota. In Jira Cloud the number of rule runs per month depends on your plan and the rule scope; check usage in the automation settings. A rule counts when it performs an action, so precise conditions save quota.
• Service limits. Rules have limits on processing time, the number of issues handled in one run and the number of actions. Very broad scheduled rules may be throttled or stopped.
• Loops. By default a rule is not triggered by another rule's actions. Enable "Allow rule trigger" only when you really need a chain, and make sure it cannot trigger itself in a cycle.

Habits that prevent surprises:

• Start narrow: one project, one issue type, then expand.
• Check the audit log after the first runs: it shows every step and the reason for failure.
• Name rules by what they do ("Bug Highest → Slack #alerts"), not "Rule 7".
• Decide who the rule actor is. Actions are performed by the automation user by default; if you switch it to a person, the rule depends on their permissions.