Short definition
A Jira automation rule is a no-code workflow that triggers actions when issues change. Each rule has one trigger (issue created, transitioned, commented, scheduled, etc.), optional conditions and branches, and one or more actions (transition, edit field, create issue, send email, call webhook). Rules are configured in project or global automation settings and execute server-side without user intervention.
Anatomy of a rule
A Jira automation rule has three parts in order:
- Trigger - what starts the rule. Examples: Issue Created, Issue Transitioned, Field Value Changed, Manual Trigger, Scheduled (cron-like), Webhook received.
- Conditions and branches - optional filters and forks.
If status = "In Progress" AND priority = Highestruns the rest only when both are true. Branches let one trigger affect multiple related issues (sub-tasks, linked issues, the epic parent). - Actions - what the rule does. Transition the issue, edit fields, create a new issue, post a comment, send Slack/email, call an external webhook.
Rules are evaluated server-side. They don’t depend on a user being logged in, and they execute as a configurable “Run rule as” user (often a service account so the audit trail stays consistent).
Rules vs. post-functions
The two overlap but aren’t interchangeable:
- Post-functions are part of the workflow definition and only fire on specific transitions. Best for actions that must happen every time that transition occurs, regardless of context.
- Automation rules are separate from the workflow, can listen to many trigger types, and have richer conditional logic. Best for cross-cutting concerns that don’t belong inside one workflow’s transitions.
A rule of thumb: if the action is “when this transition happens, always do X,” use a post-function. If it’s “in any of these projects, when any of these triggers happens, sometimes do X,” use an automation rule.
Limits
Cloud and Data Center both have rule-execution quotas. Cloud’s automation tier is bounded by monthly “rule executions” per plan. Hot rules - especially ones triggered by every comment or every field edit - can burn through quotas fast. Audit which rules account for most executions before adding more.
When automation runs out of room
Automation rules are a hammer for many problems but not all. For issue-creation scaffolding (creating a consistent set of sub-tasks under every new story), STM Issue Templates offers a richer model: declarative templates, hierarchical sub-task structures, field inheritance from parent, and conditional generation based on issue-type or component. Where automation would need a dozen rules to maintain a sub-task standard, STM keeps the same logic in one template.
See also (Redmoon products)
Common questions
What is an automation rule in Jira?
A Jira automation rule is a no-code workflow that triggers actions when issues change. Each rule has one trigger (issue created, transitioned, commented, scheduled, etc.), optional conditions and branches, and one or more actions (transition, edit field, create issue, send email, call webhook). Rules are configured in project or global automation settings and execute server-side without user intervention.
What can a Jira automation rule do?
Common actions: auto-assign issues by component, transition parent when all sub-tasks are Done, post a Slack message when a P1 is created, copy a field value from epic to story on creation, close stale issues after N days inactive, generate weekly summary tickets on a schedule, sync linked issues across projects. Almost any rule-of-thumb maintenance task is automatable.
Are automation rules the same as workflow post-functions?
No. Post-functions run inside a workflow transition and only fire when that specific transition happens. Automation rules can listen to any trigger across the project (or globally) and are configured separately from the workflow. Automation rules also have richer condition/branch logic, scheduled triggers, and a UI editor that doesn't require workflow admin.
Where can automation rules live - project or global?
Both. Project-scoped rules fire only on issues in that project and are managed by project admins. Global rules fire across all projects (or a configurable subset) and are managed by Jira admins. Library rules are templates that can be copied into multiple projects. Choose project scope when a single team needs the rule; global scope when the policy applies instance-wide.