Jira automation lives inside each project under Project settings → Automation, with site-wide rules managed by admins in global automation. A rule watches for a trigger (an event or schedule), checks any conditions you set, then runs actions like assigning work, commenting, transitioning, or sending a message. No code required.
That description covers the happy path. The parts that actually cost teams time are run limits, permission gaps, and rules that go quiet without telling anyone. This guide walks through setup, then spends most of its length on the things that break.
On this page
- Where Jira automation actually lives
- Build your first rule, step by step
- Triggers, conditions, actions, and smart values
- Three example rules with smart values
- Single-project vs global rules, and who can create them
- Run limits and what actually counts
- Troubleshooting: rules that stop firing
Where Jira automation actually lives
For a rule that runs in one project, open the project and go to Project settings → Automation. That is the screen most people are sent to, and it is where you will spend most of your time. If you administer the whole site and want a rule that spans projects, you go through global automation instead, reached from the admin Settings cog under system-level automation.
One thing to flag before you start clicking: Atlassian is mid-rename. In newer instances the same feature shows up under Space settings → Automation, rules are called flows, projects are called spaces, and issues are called work items. The builder and the concepts are identical; only the labels moved. If your screen says “flows” and “spaces,” you are in the right place. Atlassian’s own create-and-edit documentation now uses the newer wording throughout.
Build your first rule, step by step
Here is the from-scratch path. Start small: one trigger, one action, no conditions, so you can confirm it fires before you add logic.
- Open your project and select Project settings → Automation (or Space settings → Automation in newer instances).
- Select Create rule (labelled Create flow in the newer UI), then choose Create from scratch.
- Pick a trigger. For a first test, Work item created is predictable and easy to fire on demand.
- Select Add component and choose an action. A rule needs at least one action to be valid, so start with something visible like Add comment.
- Open Rule details (or Flow details) and set the Name, the Scope (which projects it runs in), the Owner (who gets error emails), and the Actor (the user the rule acts as).
- Select Turn it on to save and enable the rule.
- Create a test issue, then open the Audit log and confirm the run shows Success.
That last step is not optional in practice. A rule that saves cleanly can still do nothing at runtime because of a scope mismatch or a permission gap, and the audit log is the only place that tells you.
Triggers, conditions, actions, and smart values
Every rule is built from three kinds of components. The trigger starts the rule: an event like Work item created or Work item transitioned, a Scheduled trigger that runs on a cron-like interval, or a manual or incoming-webhook trigger. Conditions refine it, so the rule only continues when, say, the issue type is a bug or the priority is high. Actions do the work: assign, comment, edit a field, transition, or send a message to another tool.
Smart values are how you pull live data into those actions. They use double curly braces and dot notation. Common ones you will reach for constantly:
{{issue.key}}– the issue key, e.g. PROJ-142{{issue.summary}}– the issue title{{issue.assignee.displayName}}and{{issue.reporter.displayName}}{{issue.status.name}}and{{issue.priority.name}}{{now}}, with date math like{{now.plusDays(3)}}
If you are not sure a smart value resolves to what you expect, log it before you rely on it (more on that in troubleshooting). Atlassian keeps a full smart values reference that is worth bookmarking.
Three example rules with smart values
These are deliberately small. Real automation libraries are built from many rules like these, not a few giant ones.
Auto-assign and acknowledge new bugs
Trigger: Work item created. Condition: issue type equals Bug. Action: Assign to your triage lead, then Add comment: Thanks {{issue.reporter.displayName}}, {{issue.key}} is now in triage. The reporter gets a same-second acknowledgement, and nothing sits unassigned overnight.
Nudge stale in-progress work
Trigger: Scheduled, running each morning with a JQL filter such as status = "In Progress" AND updated <= -3d. Action: Add comment mentioning the assignee and noting the issue has not moved in three days. Keep the JQL tight; a broad schedule that matches thousands of issues is the fastest way to hit the limits below.
Tell the team channel about high-priority issues
Trigger: Work item created. Condition: priority equals Highest. Action: Send Slack message with {{issue.key}} ({{issue.priority.name}}): {{issue.summary}}. Setting up the connection is its own small task, covered in our Jira and Slack integration guide. If most of what you want is cross-tool notifications, compare how other tools handle it in our Asana automations walkthrough before committing.
Single-project vs global rules, and who can create them
Scope is set in Rule details, and it decides both where a rule runs and who is allowed to build it. A single-project rule is the default: a project admin can create and edit it within their own project, and it only fires there. A multi-project or global rule spans several projects or the whole site, and creating those generally requires Jira admin rights through global automation.
The other setting that trips people up is the Actor. A rule runs as whatever user is set as the actor, and it can only do what that user is permitted to do. Set the actor to someone without permission to transition an issue or edit a restricted field, and the action fails at runtime even though the rule is enabled and error-free. If a rule works in a test project and silently does nothing in another, the actor’s permissions in the second project are the first thing to check.
Run limits and what actually counts
Every Jira plan caps how many rule runs you get per month. These are the current numbers from Atlassian’s usage documentation for the Jira app:
| Plan | Jira automation runs per month |
|---|---|
| Free | 100 |
| Standard | 1,700 |
| Premium | 1,000 multiplied by the number of users |
| Enterprise | Unlimited |
Jira Service Management has its own, higher allowances, so if you run both, executions are billed to the app with the highest limit. Pricing per user changes often, so check current figures in our Jira pricing breakdown rather than trusting a number you saw last year.
What counts is where people get surprised. A run only counts when it completes and performs at least one qualifying action, and it counts once no matter how many actions it takes. Runs that perform no action because a condition stopped them do not count. Neither do a handful of specific actions on their own, including Log, Create variable, Lookup work items, and Re-fetch work item data. System rules that ship with certain templates do not count either. Usage resets on the first of each month at 00:00 UTC, and unused runs do not roll over.
Be careful here: Atlassian has changed how executions are counted before, and older guides claim single-project rules never count against your limit. The current documentation does not say that. It counts every qualifying run regardless of scope, so treat your own Usage screen as the source of truth, not a blog from two years ago. On the Free plan especially, 100 runs disappears quickly if one scheduled rule fires on a broad filter, and once you hit the cap your rules simply stop running until the reset.
Troubleshooting: rules that stop firing
Automation fails quietly, which is its worst trait. Nothing pops up to tell you a rule died. The audit log is your first and best stop for almost every problem below; open the rule, check its recent runs, and read the status on each.
The rule is toggled off, or got disabled for you. Rules can be switched off accidentally, and Jira will also disable a rule automatically when it hits certain service limits, such as a single run trying to fetch more than 5,000 associated items. If a rule stopped firing on a specific date, check whether it is still enabled before anything else.
The audit log says THROTTLED. This means the rule breached a service limit rather than a monthly run cap. Common causes are a rule exceeding the allowed processing time (60 minutes per 12 hours), too many items queued, or too many rules running at once. Concurrent-run limits scale by plan: Free allows 5 rules running simultaneously, Standard 10, Premium 20, and Enterprise 30. The fix is usually to narrow a JQL query, lengthen a schedule interval, or split one heavy rule into smaller ones.
The audit log says LOOP. Automation stops a rule that triggers itself, or a chain of rules, too many times in quick succession. If an “issue updated” rule edits the issue and re-triggers itself, you will see this. Add a condition so the rule ignores changes made by automation, or narrow the trigger.
The rule fired but did nothing. Almost always a condition blocked it or the actor lacked permission. The audit log shows which component stopped the run. If the rule works in one project and not another, compare the actor’s permissions across both.
You hit the monthly run limit. When usage runs out, rules fail to run until the first of the next month. You will usually get a warning banner in the automation screen before that happens. Audit which rules burn the most runs and tighten their triggers.
One honest closing point: automation is the wrong tool for large one-off changes. Editing thousands of issues once is a job for Jira’s bulk-change feature, not a scheduled rule that will throttle itself and eat your run allowance. And if you find yourself fighting run limits constantly on a small team, it is worth asking whether the platform fits the workload at all. Our comparisons of Jira versus Linear and the best Jira alternatives cover tools with different automation models that may suit lighter workflows better.
