Jira Automation: Rules Worth Setting Up (and Limits)

Jira automation lets you build no-code rules that change work items for you: when something happens in Jira, check a condition, then do something. Every rule starts with a trigger, such as a work item being created or moved; narrows with conditions, such as “work type is Bug”; and ends with actions, such as assigning, transitioning, commenting or sending a Slack message. Atlassian now calls a rule a flow and its parts steps. The rules worth setting up first are the boring ones: routing new bugs, moving work when code moves, closing parents, nudging stale work and flagging urgent items. Each step that runs counts against a monthly allowance shared across your organization, and service limits cap how much one flow can touch. Everything below reflects Atlassian’s documentation as of October 1, 2026.

Rules are now flows, and components are steps

If you learned Jira automation a year ago, the words have moved. Atlassian’s cloud release notes for April 13 to 20, 2026↗ (opens in a new tab) announced that “The term Rule has been replaced with Flow throughout the automation experience”, and that the builder now says “steps” instead of components. The button is Create flow. Jira itself also renamed issues to work items, issue types to work types and projects to spaces.

The rename is not finished everywhere. Trigger names say “Work item created” and “Work item transitioned”, while the conditions page still lists “Issue fields condition” and “Related issues”, and smart values still read {{issue.key}}. This post says “rule” and “flow” interchangeably, because people still search for Jira automation rules, and uses whichever step name Atlassian shows today.

The anatomy of a Jira automation rule

Atlassian’s page on automation steps↗ (opens in a new tab) defines the parts in one line each: “Every flow starts with a trigger”, conditions “must be met for your flow to continue running”, actions are “the doers of your flow”, and branches “create a separate execution path”. Around those sit a few settings that matter as much as the logic:

• Trigger: the event that starts it. Work item created, transitioned, commented or updated, a field value changed, a schedule, an incoming webhook, a manual trigger from a work item, or a DevOps event such as a branch created or a pull request merged.
• Conditions: filters that stop the flow unless they pass. Field checks, JQL, smart value comparisons and If/else blocks.
• Actions: what it does. Assign, transition, edit or comment on a work item, create subtasks, send an email, a Slack message or a Microsoft Teams message, or send a web request.
• Branches: run steps on related work items, such as the parent, the subtasks or the items a JQL query returns.
• Smart values: placeholders like {{issue.summary}} that drop the work item’s data into a comment or message.
• Scope, actor and owner: which spaces the flow runs in, which user it acts as, and who receives emails about it. Check the audit log after the first run.

Name:     Route new checkout bugs
Scope:    Space WEB
Trigger:  Work item created
If:       Issue fields condition — Work type equals Bug
And:      Issue fields condition — Component equals Checkout
Then:     Assign work item — Dana Lee
Then:     Send Slack message — #checkout:
          "New bug {{issue.key}}: {{issue.summary}}"

Jira automation rules worth setting up first

Start with flows that remove a step somebody already does by hand every day. Build one, watch its audit log for a week, then add the next.

1. Route new bugs. Work item created, a condition on work type and component, then Assign work item. Components exist only in company-managed spaces; in a team-managed space, use a label instead.
2. Move work when code moves. The DevOps triggers Branch created and Pull request created can transition the work item to In Progress, and Pull request merged can move it on. They need your Bitbucket, GitHub or GitLab connected to Jira.
3. Close the parent when the children are done. Trigger on Work item transitioned to Done, branch to the parent, check that all its subtasks are done, then Transition work item.
4. Nudge stale work. A Scheduled trigger with a JQL query, such as the one below, then Comment on work item mentioning the assignee. Atlassian notes that a scheduled flow that fails 10 times in a row disables itself.
5. Flag urgent items. Work item created with priority Highest, then Send Slack message or Send Microsoft Teams message to the on-call channel.
6. Ask a person before reopening. Work item commented by the reporter on a Done item, then a comment that tags the owner, rather than an automatic reopen. Automation should notify; a person decides.

status = "In Progress" AND updated <= -10d ORDER BY updated ASC

A well-written work item makes every one of these flows more reliable, because conditions can only check fields that someone filled in. Our guide to writing a Jira ticket covers the fields worth keeping tidy.

Jira automation limits: usage and service

Two kinds of limit apply. The first is usage. Atlassian’s page on how automation usage is calculated↗ (opens in a new tab) says automation has “moved from per app monthly flow limits to usage-based automation steps pooled at the organization level”. Each trigger, condition, action, branch and loop that runs counts as one step, including runs that end in no match. The monthly Jira allowances it lists are:

• Free: 150 steps per month for the whole subscription.
• Standard: 400 steps per user per month.
• Premium: 750 steps per user per month.
• Enterprise: 1,000 steps per user per month.

Allowances refresh monthly and are shared across your Atlassian apps. If extra usage is turned off and you reach the full allowance, flows stop until the next reset; Atlassian says billing for extra usage takes effect on December 3, 2026. Organization admins can see usage under Insights, then Platform usage. Because a condition that stops a flow still costs steps, the cheapest saving is a narrower trigger: scope a flow to the spaces that need it, and prefer one scheduled JQL flow over a flow that fires on every update.

The second kind is service limits, which protect performance. Atlassian’s automation service limits↗ (opens in a new tab) include 60 minutes of processing time per 12 hours, 5,000 items fetched by a single flow run (breach it and the flow is disabled), 50,000 items queued across the site, and loop detection that stops a flow after it triggers itself 10 times in quick succession. Concurrent flow runs are capped by plan: 5 on Free, 10 on Standard, 20 on Premium and 30 on Enterprise. Some advanced steps, such as running branches at the same time, are Premium and Enterprise only.

AI inside Jira automation

There are now three ways AI shows up in a flow. Create with Rovo builds a draft flow from a description; Atlassian’s page on creating flows with Rovo↗ (opens in a new tab) says the flow needs at least a trigger and an action, that “The quality, accuracy, and reliability of flows created with Rovo may vary”, and that Rovo is not available in Atlassian Government environments. Review the draft step by step before you turn it on.

The Use Rovo agent action prompts an agent, for example to review the quality of a work item’s description, and passes its answer to a second action such as Add comment. Atlassian’s guide to agents in automations↗ (opens in a new tab) explains that an agent with write tools can update work items, create pages or post comments with the permissions of the user who set it up. Atlassian’s July 2026 release notes also list a Claude agent action, rolling out, that sends a custom prompt to Claude from a flow. Treat any of these like a new teammate: have its first flows comment rather than edit, and read the comments for a week.

AI assistants over MCP: the other direction

Automation runs inside Jira. An AI assistant connected over MCP works from outside: Claude, Cursor or GitHub Copilot calls Atlassian’s Rovo MCP Server with your account and your permissions, and searches, creates, edits and transitions work items in conversation. The published tools do not edit automation flows, so building and changing flows stays in Jira’s own screens. Edits the assistant makes are edits by your account, so test whether your existing flows react to them the way you expect. For setup, pick your client:

• Jira MCP with Claude Code: the one command, sign-in, prompts and limits.
• Jira MCP in Cursor: the plugin or an mcp.json entry, and approvals.
• Jira MCP with GitHub Copilot: the VS Code setup.
• Jira MCP for Data Center: the options when Jira is self-hosted.
• Jira MCP vs the Jira API: when a script beats an assistant.
• What the Jira MCP server can do: the tools and their permission groups.

When you need fewer rules, not more

Automation exists to keep a configurable tool consistent. A team of three with one product sometimes spends more time maintaining flows than the flows save. fenbs takes the opposite approach: it has no automation flows, triggers or step allowances at all. The board is fixed, with lanes To Do, Next Up, In Progress and Completed, and the work that flows would do is done by people and by AI assistants connected over MCP as members with a role. A person can mark a task with a plan as pre-approved for AI, with limits; an assistant takes it, does what the plan says, fills in the test status and moves it to Completed, and a person checks it. The history records each change and who made it.

What you give up is real: no scheduled jobs, no Slack messages on events, no sprints, no due dates and no settable assignee. If your process depends on those, stay with Jira and use the flows above. The side-by-side is on fenbs vs Jira.