Jira Automation Rules: Examples and CLI Equivalents

atlassian-cli is an independent, community open-source project, not affiliated with, endorsed by, or sponsored by Atlassian, and is not Atlassian's official CLI (acli). Product names are used only to identify compatibility.

What Jira automation rules are made of

Jira automation rules are no-code "when this happens, do that" workflows that run inside Jira Cloud. Every rule is assembled from three building blocks: a trigger that starts it, one or more conditions that decide whether to continue, and one or more actions that change your issues. Understand those three pieces and you understand every rule you will ever read.

This post takes each building block in turn and shows the command-line equivalent, so you can reproduce the same logic as an explicit, version-controlled script with atlassian-cli. That is useful when you want the rule reviewed in a pull request, run in CI, shared across projects, or wired into steps that live outside Jira.

One thing to be clear about up front: atlassian-cli does not build or edit server-side automation rules. There is no rule builder in the CLI. What it gives you is the imperative version of each trigger, condition, and action, plus commands to inventory the rules you already run. If you want the overview first, start with the Jira automation guide; for a library of ready-made recipes, see Jira automation examples. This piece is the block-by-block mapping.

Triggers and their CLI equivalents

A trigger is whatever kicks a rule off. Native Jira offers scheduled triggers, issue-created triggers, transition triggers, field-changed triggers, and manual triggers, among others. On the command line, a trigger becomes two things working together: a scheduler (cron, a CI schedule, or a git hook) and a jira issue search query that finds the issues the trigger would have fired on.

For a scheduled trigger the mapping is direct: whatever interval the rule runs on, cron runs the query on. For event triggers such as "issue created" you approximate the event by polling with a time-bounded JQL clause, so you only pick up issues that appeared since your last run.

Polling has one honest trade-off worth naming: it is not instant. A native "issue created" trigger reacts the moment the issue is saved, while a five-minute cron sees it on the next tick. For work that must happen within seconds, keep the trigger native. For everything measured in minutes or hours, which is most housekeeping, polling is perfectly adequate and far easier to audit. Match your polling window to your JQL window so the two never drift: if cron runs every five minutes, gate the query on the same five-minute lookback.

# A "scheduled" trigger, rebuilt as a query you can cron.
# Finds the issues a rule would fire on this morning.
atlassian-cli jira issue search \
  --jql "project = DEV AND status = 'In Review' AND updated <= -3d" \
  --format json

# An "issue created" trigger, approximated by polling every 5 minutes.
atlassian-cli jira issue search \
  --jql "project = DEV AND type = Bug AND created >= -5m" \
  --format json

Conditions and their CLI equivalents

Conditions are the gates. After a trigger fires, conditions decide whether the rule keeps going. Native Jira has JQL conditions, field conditions, user conditions, and related-issue conditions. On the command line you express a condition in one of two places: inside the JQL (a server-side gate) or as a post-filter on the JSON output with jq (a client-side gate).

Server-side is cheaper and usually clearer: fold the condition straight into the query so Jira only returns issues that already pass. Use the client-side filter when the check depends on data you have to inspect field by field, or on logic JQL cannot express.

# A condition, expressed two ways.

# 1. Inside the JQL, the server gates for you
atlassian-cli jira issue search \
  --jql "project = DEV AND priority = Highest AND assignee is EMPTY"

# 2. As a post-filter with jq, the client gates
atlassian-cli jira issue search --jql "project = DEV" --format json \
  | jq '[.[] | select(.fields.labels | index("needs-triage"))]'

The --envelope flag is handy here: it wraps list output in {"data": [...], "count": N}, which makes downstream parsing and counting more predictable when you chain several conditions together.

Actions and their CLI equivalents

Actions are the payload: the change the rule actually makes. This is where atlassian-cli lines up most directly with native automation, because most actions map one-to-one to a Jira issue verb. The issue verbs are search, get, create, update, transition, assign, and delete; the jira bulk group applies transition, assign, and export across many issues at once.

Not every native action has a CLI counterpart, and it is important to say so rather than invent one. Sending an email, posting a comment, or pinging Slack are best left to native rules (or to a shell step you add around the CLI). The CLI shines at the state-changing actions: moving issues, reassigning work, editing fields, and creating follow-ups.

# Action: transition an issue
atlassian-cli jira issue transition DEV-123 --transition "Done"

# Action: assign an issue
atlassian-cli jira issue assign DEV-123 --assignee triage@example.com

# Action: edit a field
atlassian-cli jira issue update DEV-123 --summary "[Triaged] Login fails on Safari"

# Action: create a follow-up issue
atlassian-cli jira issue create --project DEV --issue-type Task \
  --summary "Follow-up: add regression test"

A full rule, rebuilt on the command line

Now stitch a trigger, a condition, and an action into a single rule. Consider a common native rule: every weekday morning, find issues that have sat in "In Review" for three days with no assignee, and move them to "Needs Owner" so they stop hiding. Here it is as one script, with a dry-run so nothing changes until you are sure.

#!/bin/bash
# Native rule equivalent:
#   TRIGGER    every weekday at 09:00 (handled by cron below)
#   CONDITION  in "In Review" > 3 days, still unassigned
#   ACTION     move to "Needs Owner"
set -euo pipefail

JQL="project = DEV AND status = 'In Review' AND assignee is EMPTY AND updated <= -3d"

# Preview what the rule would touch, always dry-run first
atlassian-cli jira bulk transition \
  --jql "$JQL" \
  --transition "Needs Owner" \
  --dry-run

# Remove --dry-run to execute for real:
# atlassian-cli jira bulk transition --jql "$JQL" --transition "Needs Owner"

The trigger lives in your scheduler. A cron entry gives you the same "every weekday at 09:00" cadence a scheduled rule would, and the script's output goes to a log you can grep later.

# /etc/cron.d/jira-needs-owner, 09:00, Monday to Friday
0 9 * * 1-5  ops  /opt/scripts/needs-owner.sh >> /var/log/jira-rule.log 2>&1

Two habits keep a rebuilt rule safe. First, make it idempotent: because the JQL selects only issues still in the wrong state, running the script twice in a row is harmless, since the second run finds nothing left to change. Second, always dry-run before the first live run and after any JQL edit, so a stray clause never sweeps up issues you did not mean to touch. These are the same guardrails a careful native rule uses; the difference is that here they live in a file you can read.

Because the whole rule is now a file, you get things a UI rule cannot give you: a git history of every change, pull-request review before it ships, and the freedom to add non-Jira steps (upload the log to S3, post a summary, open a ticket elsewhere) in the same script. For a production-grade version with argument parsing and confirmation prompts, see the Jira bulk transition runbook.

Native automation vs a CLI script

Rebuilding a rule on the command line is not always the right call. The two approaches are complementary, and the honest answer for most teams is "use both." Native automation is unbeatable for instant, event-driven reactions; a CLI script wins when you care about version control, portability, and steps that reach outside Jira.

A practical split: keep the fast, reactive rules (assign on create, comment on transition) native, and move the periodic, auditable work (nightly cleanups, weekly reports, cross-project sweeps) into scheduled CLI scripts you can review like any other code.

Auditing the rules you already have

Even if you never rebuild a rule, the CLI is worth having for visibility. Automation rules multiply quietly, and few teams can list every rule running against a busy project. These read-only commands give you an inventory and a change history.

# List the automation rules configured on your instance
atlassian-cli jira automation list

# See what changed, and when
atlassian-cli jira audit list --from 2026-06-01 --limit 100

# Inventory webhooks, often the other half of external automation
atlassian-cli jira webhooks list

Pipe any of these to JSON and store the result, and you have a snapshot you can diff over time to catch rule drift, an unexpected new rule, or a change nobody announced.

# Snapshot today's rules; commit it and diff on the next run
atlassian-cli jira automation list --format json > automation-snapshot.json

For the full list of verbs and flags behind these examples, see the command reference, and browse the Jira CLI hub for the rest of the issue, project, and bulk commands.

FAQ

Related Resources