All insights
Atlassian

10 Jira automation rules every admin should ship in week one

Copy-paste-ready automation rules — auto-assign by component, SLA escalations, parent/child sync, Slack notifications and more.

May 5, 202613 min readArventra Technologies team

Jira's built-in automation is the single highest-leverage feature most admins underuse. The free tier alone gives you 500 rule executions per user per month — more than enough to eliminate the manual work that eats hours out of every PM, support lead, and engineering manager's week. This post is the 10 rules we ship in the first week on virtually every Jira project we configure at Arventra.

Every rule below is copy-paste-ready with the trigger, conditions, actions, and the specific Jira UI path to build it. Each one solves a problem we've seen on real client engagements, and together they typically save a 20-person team 8–12 hours per week.

The 10 rules at a glance

#RuleTime saved / week
1Auto-assign by component2–3 hrs (triage)
2SLA breach escalationPrevented misses
3Parent/child status sync1 hr (manual updates)
4Slack on high-priorityFaster response
5Cross-project linking2 hrs (manual linking)
6Auto-close stale tickets1 hr (manual cleanup)
7Re-open on customer replyPrevented dropped issues
8Auto-link duplicates2 hrs (duplicate triage)
9Story-point sanity checkBetter estimates
10Release notes draft3 hrs (per release)

1. Auto-assign by component

Trigger: Issue Created.
Condition: Component is set.
Action: Assign issue to component lead (use a smart value: {{issue.components.first.lead}}).

This single rule eliminates the daily triage meeting on its own. Set component leads once via Project Settings → Components, and every new ticket is routed automatically.

2. SLA breach escalation

Trigger: SLA "Time to first response" → at 75% consumed.
Action 1: Add team lead as watcher.
Action 2: Send Slack message to #support-escalations:

⚠️ SLA at 75% — {{issue.key}}
Priority: {{issue.priority.name}}
Summary: {{issue.summary}}
Reporter: {{issue.reporter.displayName}}
{{issue.url}}

3. Parent / child status sync

Trigger: Issue Transitioned.
Condition: Issue has a parent AND all sibling issues are Done.
Action: Transition parent Epic / Story to Done.

One of the most-requested features in every retrospective. Five minutes to build, eliminates "is this epic actually done?" Slack threads forever.

4. Slack notification on high-priority creation

Trigger: Issue Created.
Condition: Priority in (Highest, High).
Action: Send Slack message to the relevant team channel:

🚨 New {{issue.priority.name}} priority: {{issue.key}}
{{issue.summary}}
Reporter: {{issue.reporter.displayName}}
{{issue.url}}

5. Cross-project linking (Support ↔ Engineering)

Trigger: Issue Created.
Condition: Project = SUPPORT AND Summary contains "[BUG]".
Action: Create issue in ENGINEERING project, copy summary and description, link as "caused by".

Closes the support-to-engineering loop without humans manually copying tickets between projects. Engineering sees the original support context, support sees engineering's progress.

6. Auto-close stale "Waiting for customer" tickets

Trigger: Scheduled — daily at 09:00.
JQL filter:

status = "Waiting for customer"
AND updated < -7d
AND resolution = Unresolved

Action 1: Add comment explaining the auto-close and how to re-open.
Action 2: Transition to Closed with resolution "Won't Do".
Action 3: Notify customer via email.

7. Re-open on customer reply

Trigger: Comment Added.
Condition: Comment author = Reporter AND status in (Closed, Resolved).
Action 1: Re-open issue (transition to "In Progress").
Action 2: Notify previous assignee.

8. Auto-link related issues

Trigger: Issue Created.
Condition: Lookup issues with JQL:

project = {{issue.project.key}}
AND status != Done
AND text ~ "{{issue.summary}}"
AND key != {{issue.key}}

Action: If matches found, add "relates to" link and comment pointing to matches.

Cuts duplicate-bug noise dramatically. Reporters see "here's an existing ticket about the same thing" instead of opening a third copy.

9. Story-point sanity check

Trigger: Issue Transitioned to In Progress.
Condition: Story Points is empty.
Action: Post a Slack reminder to assignee (or block the transition entirely if you prefer hard enforcement).

We typically start with reminders, then escalate to blocking after a month if the team agrees.

10. Release notes draft

Trigger: Version Released.
Action 1: Look up all issues with fixVersion = {{version.name}}.
Action 2: Create Confluence page from "Release Notes" template, pre-populated with the issue list grouped by type (Features, Bugs, Improvements).
Action 3: Post the page link to the release Slack channel.

Turns a 30-minute manual chore into a 30-second review-and-publish.

Automation hygiene (the rules behind the rules)

Three rules we enforce on every Jira instance we run, regardless of automation count:

  • Name every rule clearly[Support] Auto-close stale waiting-for-customer, not Rule 23. Future-you will thank you.
  • Set a rule owner in the rule description. A rule with no owner is a future incident.
  • Review the audit log monthly for failures. Failed rules are silent until they aren't — and silent failures erode trust in automation across the team.
  • Test in a sandbox project first when the rule has destructive actions (transitions, closures, notifications). One misconfigured rule can spam thousands of users.
  • Use rule disabled state, not deletion, when retiring a rule — you keep the audit history and can re-enable if needed.

Frequently asked questions

Does Jira automation cost extra?

Free up to 500 rule executions per user per month on Cloud Free, scaling up with paid tiers. For most teams the free allowance is enough; Cloud Premium adds unlimited global rules and cross-project automation.

What's the difference between project and global automation?

Project automation runs within one Jira project. Global automation runs across multiple projects from a single rule — useful for cross-project linking and instance-wide policies. Global rules require admin permissions and are Premium-tier on Cloud.

Can automation rules call external APIs?

Yes — the "Send web request" action posts to any HTTPS endpoint with custom headers and JSON body. We use this to trigger CI builds, post to incident-management tools, and update internal dashboards.

How do we test rules without spamming real users?

Atlassian Cloud has a sandbox environment (Premium tier) that mirrors production. For Free/Standard tiers, create a dedicated test project, run the rule there first, and only promote to production projects once verified.

What's the smart value cheat sheet?

The most common ones we use: {{issue.key}}, {{issue.summary}}, {{issue.url}}, {{issue.priority.name}}, {{issue.reporter.displayName}}, {{issue.components.first.lead}}, {{now.plusBusinessDays(2)}}. Atlassian's documentation has the full reference.

Want this configured for you?

Want a fully configured Jira instance with these ten rules and our extended pack of 30+ rules on day one? Our Atlassian consulting team ships pre-built automation packs as part of every engagement.

Need a senior team that ships this kind of work?