JIRA Automation Rules

Every project team performs certain repetitive actions regularly — closing related issues when a parent is done, sending a reminder when an issue sits untouched for days, or assigning a task automatically when it moves to a specific status. Doing these manually wastes time and introduces human error. JIRA Automation Rules handle these actions automatically without any programming knowledge required.

This topic explains how automation works in JIRA, how to build rules from scratch, and how to use the most common automation patterns that real teams rely on daily.

What Is a JIRA Automation Rule?

A JIRA Automation Rule is an instruction that tells JIRA: "When this specific event happens, check these conditions, then take this action." The rule runs silently in the background and executes the action the moment the trigger event occurs.

Think of it like an automatic door sensor. The sensor (trigger) detects movement, checks if the door is already open (condition), and then opens the door (action) — all without any human input.

The Three Building Blocks of Every Rule

┌──────────────────────────────────────────────────────────┐
│                   AUTOMATION RULE                        │
├──────────────────────────────────────────────────────────┤
│                                                          │
│   TRIGGER          CONDITION           ACTION            │
│   ─────────        ─────────────       ──────────────    │
│   What starts      What must be        What JIRA does    │
│   the rule         true to proceed     automatically     │
│                                                          │
│   Example:         Example:            Example:          │
│   Issue moved      Priority must       Send email to     │
│   to "Done"        be "Critical"       the reporter      │
│                                                          │
└──────────────────────────────────────────────────────────┘

• Trigger: The event that starts the rule. Without a trigger, the rule never runs.
• Condition: An optional check that must be true before the action executes. Conditions prevent the rule from acting on the wrong issues.
• Action: The task JIRA performs automatically — transition an issue, send a comment, assign a user, create a sub-task, and more.

Where to Access Automation in JIRA

JIRA provides automation at two levels — project level and global level. The access path differs for each.

Project-Level Automation

1. Open the JIRA project
2. Click Project Settings at the bottom of the left sidebar
3. Select Automation from the settings menu
4. The automation library opens, showing all existing rules and a button to create new ones

Global Automation (Jira Admin Only)

1. Click the Settings (gear icon) in the top-right corner
2. Select System
3. Click Automation Rules under the Advanced section

Project-level rules apply only to that project. Global rules can target multiple projects or all projects at once.

Creating a New Automation Rule

The rule builder in JIRA uses a step-by-step visual interface. No code is required at any point.

Step-by-Step: Build a "Auto-Assign on Status Change" Rule

This example creates a rule that automatically assigns an issue to the QA team member whenever the issue moves to the "In Review" status.

1. Open Project Settings → Automation
2. Click Create rule in the top-right corner
3. Choose trigger: Issue transitioned
4. Set the transition: From any status → To In Review
5. Click Add component → Add condition
6. Choose Issue fields condition → Set: Issue Type = Story
7. Click Add component → Add action
8. Choose Assign issue → Select the QA team member
9. Give the rule a clear name: Auto-assign to QA on In Review
10. Click Turn it on

Rule: Auto-assign to QA on In Review

TRIGGER           CONDITION              ACTION
─────────────     ──────────────────     ─────────────────────
Issue             Issue Type             Assign issue to
transitioned  →   equals Story       →   QA Engineer (Maya)
to "In Review"

Types of Triggers

JIRA offers a wide range of triggers. Choosing the right trigger is the most critical step in building a useful rule.

Types of Conditions

Conditions prevent automation rules from acting on every single issue that matches the trigger. Adding a condition narrows the scope so the action only runs when it truly makes sense.

Commonly Used Conditions

Types of Actions

Actions are the tasks JIRA executes when a rule runs successfully. Multiple actions can be added to a single rule, and they execute in sequence from top to bottom.

Using Smart Values in Automation

Smart Values are dynamic placeholders that pull live data from the issue and insert it into fields, comments, or messages during rule execution. They work like fill-in-the-blank templates.

Common Smart Values

Example: Auto-Comment With Smart Values

Action: Add comment
Comment text:
"Hi {{issue.assignee.displayName}}, the issue {{issue.key}}
has been moved to In Review. Please complete the review
by {{now.plusDays(2)}}."

Result on issue PROJ-201 assigned to Ravi:
"Hi Ravi, the issue PROJ-201 has been moved to In Review.
Please complete the review by 15-Apr-2026."

Rule Chaining — Linking Multiple Rules

Rule chaining allows one automation rule to trigger another. This is useful for complex workflows that span multiple issues or projects.

Example: Close All Sub-Tasks When Parent Is Closed

Parent Issue: PROJ-100 → Moved to "Done"

Rule 1 Trigger:
  Issue transitioned to Done

Rule 1 Action:
  Run automation for sub-tasks

Rule 2 Trigger (runs on each sub-task):
  Issue transitioned (from parent rule)

Rule 2 Action:
  Transition sub-task to "Done"

Result:
  PROJ-100-1 → Done ✓
  PROJ-100-2 → Done ✓
  PROJ-100-3 → Done ✓

Monitoring and Managing Automation Rules

After creating rules, the Automation section provides tools to monitor their performance and catch any errors.

Audit Log

Every time a rule runs, JIRA records an entry in the Audit Log. The log shows:

• The timestamp when the rule executed
• The issue that triggered the rule
• Whether the execution succeeded or failed
• The specific step that failed if an error occurred

The Audit Log is the first place to check when a rule does not appear to be working as expected.

Enabling and Disabling Rules

Rules can be turned on or off using the toggle switch in the rule list view. Disabling a rule does not delete it — it simply pauses execution until re-enabled. This is useful when testing changes or during project freezes.

Cloning Rules

An existing rule can be cloned to create a similar rule for another project or use case. After cloning, modify only the parts that differ. This saves time when setting up rules across multiple projects.

Practical Automation Rule Examples

Example 1: Notify Reporter When Issue Is Resolved

Trigger  → Issue transitioned to "Done"
Condition → Reporter is not the same as Assignee
Action   → Send email to {{issue.reporter.emailAddress}}
           Subject: "{{issue.key}} has been resolved"

Example 2: Flag Stale Issues

Trigger   → Scheduled (runs every Monday at 9:00 AM)
Condition → JQL: status != Done AND updated <= -7d
Action    → Add label "stale"
            Add comment: "This issue has not been
            updated in 7 days. Please review."

Example 3: Create a Review Sub-Task on Story Completion

Trigger   → Issue transitioned to "Done"
Condition → Issue Type = Story
Action    → Create sub-task
            Summary: "Code Review for {{issue.summary}}"
            Assignee: Team Lead

Key Points

• Every automation rule contains three parts: a trigger, an optional condition, and one or more actions
• Conditions prevent rules from running on the wrong issues — always add conditions to high-impact rules
• Smart Values insert live issue data into comments, emails, and field updates dynamically
• The Audit Log shows every rule execution and error — check it first when debugging
• Rules can be cloned across projects to save setup time
• Scheduled triggers allow rules to run at specific times, not just in response to user actions
• Rule chaining connects multiple rules to handle complex multi-issue workflows