Blog · 3 October 2026

Jira workflow automation: what to automate, and which tool does it

Jira workflow automation means letting Jira move work through its statuses, fill in fields and create the next piece of work without someone clicking each step. In Jira Cloud it comes from three places: the workflow's own transition rules (conditions, validators and post functions), Jira Automation rules that react to events around the workflow, and scheduled creation for the work that nothing triggers except the calendar. Most teams only need the first two. This guide shows what each one is for, how to set it up, what it spends, and where the third one fits.

Statements about Jira Cloud and Jira Automation are as of October 2026, from Atlassian's own documentation. Atlassian now calls an issue a work item and a project a space. This guide uses the older words where most admins still do.

The three layers of Jira workflow automation #

Before building anything, decide which layer the job belongs to. Each one answers a different question.

Put a rule in the lowest layer that can do the job. A transition rule is enforced every time and costs nothing to run. An Automation rule is more flexible and is metered. Scheduled creation is its own problem, because no event ever happens to start it.

Layer 1: rules inside the workflow itself #

Every transition in a company-managed workflow can carry its own rules. Atlassian's documentation lists them:

Conditions – check that a transition should be performed by the user. Validators – check that any input to the transition (for example, by a user) is valid, before the transition is performed. Post functions – carry out additional processing, after a transition is performed.

There are also triggers on a transition, which move a work item when something happens in a connected development tool such as Bitbucket. Creating a branch can move an issue from To Do to In Progress with nobody touching Jira.

Conditions: who can see the button #

A condition decides whether a person can perform a transition at all. Typical uses:

• only the reporter can close their own request;
• only people with a given permission can approve;
• the transition is available only if code has, or has not, been committed against the issue.

When a condition fails, the person simply does not see that transition button. That makes conditions good for keeping the board tidy and bad for explaining anything: nobody is told why the button is missing.

Validators: check the input before the move #

A validator checks what the user entered on the transition screen. Atlassian's wording is precise about what happens when one fails:

If a validator fails, the work item does not progress to the destination status of the transition, and the transition's post functions are not executed.

Use validators for the rules people forget: a resolution must be set before Done, a fix version is required before Released, a time estimate is required before In Progress.

Post functions: what happens after the move #

Post functions run once a transition has happened. Every transition already carries the essential ones: it sets the new status, adds any comment entered on the screen, updates the change history and re-indexes the issue. On top of those you can add your own, for example:

1. assign the issue to the person who performed the transition;
2. clear the resolution when an issue is reopened;
3. set a field such as a due date or a label;
4. fire an event, which in turn sends a notification.

To add any of them: go to Settings → Work items → Workflows, choose Edit on the workflow, select the transition arrow, then open Conditions, Validators or Post functions in the properties panel.

What this layer cannot do. It only acts on the issue that is moving. It cannot update a parent, create a follow-up in another project, or do anything on a schedule. For that, you need Automation.

Layer 2: Jira Automation around the workflow #

Jira Automation rules are built from a trigger, optional conditions and actions. For workflow automation the trigger that matters most is Work item transitioned, and Atlassian is explicit that it is the right one for status changes: to run a rule when a work item's status changes, use Work item transitioned instead of Work item updated.

Rules that teams build most often around a workflow:

• Close the parent when the last subtask is done. Trigger: work item transitioned to Done. Branch to the parent, check its other subtasks, transition it.
• Start the parent when the first subtask starts. The same shape in the other direction.
• Create a follow-up on resolution. When a bug moves to Done, create a verification task in the QA project.
• Auto-assign on entry to a status. When an issue enters In Review, assign it to the component lead.
• Move work from a pull request. The DevOps triggers (branch created, pull request merged, deployment successful) cover what workflow triggers do, with more conditions available.
• Nudge on a stale status. A scheduled rule with a JQL query finds issues sitting in In Progress for more than a week and comments on them.

If you want ready examples, Jira automation examples walks through six rules step by step, and automate Jira ticket creation compares the five triggers that create work.

What Automation spends #

This is the part that catches teams out. As of October 2026, Atlassian meters automation in steps, and a step is every executed part of a rule: the trigger, each condition, each action, each branch and loop.

The allowance is pooled across your organization's Atlassian apps. Extra usage is billed at $0.50 per 1,000 additional steps, and Atlassian's usage page states that extra usage billing takes effect on December 3, 2026. If extra usage is disabled and the organization reaches 100% of its allowance, automation flows stop running until the allowance resets. A rule that fires on every transition in a busy project can spend more in a week than a scheduled rule does in a year, so watch the busiest triggers first. Jira Automation pricing has the full arithmetic.

This is the strongest argument for doing as much as possible in Layer 1. A post function that sets a field on every transition spends nothing.

Layer 3: work that has to start on its own #

Both layers above react to something. A transition happened; a field changed; a pull request merged. A lot of real work has no such event. The monthly access review, the weekly report, the quarterly patch window and the sprint retrospective ticket exist because a date arrived, and if nobody creates them, the workflow never starts.

Jira Automation handles this with the Scheduled trigger, which runs a rule at a fixed interval or on a cron expression, and the rule's action creates the issue. That works, and for one or two rules it is often all a team needs. Three things to know before relying on it for many:

• Each run spends steps from the same pooled allowance as every other rule.
• A failing scheduled rule switches itself off. Atlassian's trigger reference says that scheduled flows that reach a Failure status for 10 consecutive executions will disable automatically.
• The calendar is generic. There is no project working week or holiday list, so a rule set to fire on the first of the month fires on a public holiday. Jira holidays covers where Jira does and does not respect them.

A scheduling app is the other way to fill this layer. Recurring Work Items for Jira is one: a rule is a schedule plus an issue template, written once in one project, and from then on the app creates the issue for you. What it does that matters for workflow automation:

• It feeds Layers 1 and 2 instead of replacing them. The issue it creates enters your workflow at its first status like any other, so every condition, validator, post function and Automation rule you built applies to it.
• It spends no Automation steps. The scheduling is the app's own and never creates or runs a Jira Automation rule.
• It knows the project's working week and holidays, and a rule can skip or move an occurrence that lands on a day off.
• Every run is recorded. Created, skipped or failed, each run the app claims is a row in the rule's History with its reason, so a rule that stopped working says so. A day off that the rule is set to skip creates nothing and leaves no row.
• Dynamic titles and subtask checklists, so "Access review: March 2026" arrives with its five subtasks already attached. The token reference lists what a title can carry.

It is scoped to one project at a time and runs on Jira Cloud only. If you already have scheduled Automation rules, the app can import them from an Automation export.

Which layer should handle the job? #

A quick way to decide, job by job:

How to set up Jira workflow automation, start to finish #

1. List the manual clicks. For one week, note every time someone moves an issue, fills the same field or creates the same ticket by hand. That list is your backlog.
2. Sort each item into a layer using the table above. Anything that acts only on the moving issue goes to Layer 1.
3. Build the transition rules first. They are free and they make later Automation simpler, because the data they enforce is always present.
4. Add Automation rules for cross-issue work, one at a time, each with a clear name and an owner. Open the rule's audit log after its first few runs.
5. Check your step usage in Atlassian Administration after a week, before adding more.
6. Move the calendar-driven work to scheduled creation, either as scheduled rules or in an app, and check that each created issue lands in the right first status.
7. Review quarterly. Rules outlive the reasons they were written. Disable the ones nobody would miss.

When the manual way is enough #

Not every workflow needs automating.

• A small team with a simple workflow (To Do, In Progress, Done) gains little from post functions. Dragging a card is already one action.
• A one-off or rare recurring task, such as an annual licence renewal, is fine as a calendar reminder and a ticket created by hand.
• Team-managed spaces have a simpler workflow editor with rules of their own, and many teams never need more than that.
• If nobody owns the rules, do not build many. An Automation rule that silently stops is worse than a manual step everyone knows about.

Automate the steps people forget or resent first. A step that takes two seconds can wait.

Frequently asked questions #

Is Jira workflow automation free? Conditions, validators, post functions and workflow triggers are part of the workflow and do not spend Automation steps. Jira Automation rules spend steps from your plan's monthly allowance, as of October 2026.

What is the difference between a post function and an Automation rule? A post function runs as part of a transition and acts on that issue only. An Automation rule runs after an event, can act on other issues and other projects, and is metered.

Can Jira create issues on a schedule? Yes. Jira Automation's Scheduled trigger can create issues at an interval or on a cron expression, spending steps on each run. A scheduling app such as Recurring Work Items for Jira does the same without using Automation, with working days, holidays and a run history per rule. See Jira recurring tasks for the options compared.

Why did my scheduled Automation rule stop? Either the organization ran out of steps with extra usage disabled, or the rule failed ten times in a row and disabled itself. Check the rule's audit log and your usage in Atlassian Administration.