Atlassian Automation is the most underused feature in most Jira deployments. Teams pay for Premium to get it, then use it for one rule that closes resolved tickets. The platform can do dramatically more — the gap is knowing what to build.
This guide covers what the native rule engine actually supports, where it runs out of road, when ScriptRunner closes the gap, and when you need a custom integration. Costs are 2026 market rates.
What Atlassian Automation Covers
The rule engine spans three products from a single interface: Jira Software, Jira Service Management, and Confluence. A trigger in one product can fire actions in another — a sprint ending in Jira Software can auto-create a retrospective page in Confluence, for example.
Run limits by plan:
- Free: 500 rule runs per month
- Standard: 1,500 runs per month
- Premium: Unlimited runs, cross-project rules enabled
- Enterprise: Unlimited runs plus audit log and advanced admin controls
A "run" is one trigger-to-action execution. A rule that processes 200 tickets a day will hit the Standard limit in about a week. At that scale, Premium pays for itself immediately.
The 10 Most Valuable Native Automation Rules
These are the rules with the highest time-to-value ratio. Each can be configured in the native rule editor without ScriptRunner or code.
| Rule | Trigger | Action | Time saved |
|---|---|---|---|
| Auto-assign by component or label | Issue created | Assign to team member based on component | 2–4 hrs/week for triage |
| SLA breach pre-alert (30 min before) | Scheduled: SLA approaching | Comment + notify assignee | Eliminates SLA breaches from missed deadlines |
| Auto-transition blocked ticket when blocker resolves | Linked issue status change | Transition blocked issue to In Progress | Removes manual follow-up on blockers |
| Sync Jira status to linked Confluence page | Issue status change | Update Confluence page label or property | Keeps spec pages accurate without manual updates |
| Sprint retrospective auto-create at sprint end | Sprint completed | Create Confluence page from template | 15–20 min saved per sprint |
| Requester notification on ticket assignment | Issue assigned | Email or comment to reporter | Reduces "what's the status?" DMs |
| Escalate P1 tickets unresponded after 1 hour | Scheduled: time since creation | Add watcher, set priority, comment | Catches dropped P1s before they become incidents |
| Auto-close stale tickets (7 days, with comment) | Scheduled: last updated date | Transition to Done with explanation comment | Keeps backlog clean automatically |
| Parent issue auto-progress when all children done | Sub-task status change | Transition parent if all sub-tasks resolved | Removes manual epic management |
| Daily digest of open items by assignee | Scheduled: daily at 9am | Send email summary of open issues per user | Replaces manual standup prep |
Where Native Automation Stops
Five hard limits define the ceiling of what the native rule editor can do. These are not bugs — they are deliberate scope boundaries.
1. No external HTTP calls with custom logic
The native Send Web Request action can POST to a webhook, but you cannot inspect the response and branch on it. You cannot call your internal API, read the result, and use it to decide what to do next. The action fires and forgets.
2. No persistent state between runs
Each rule execution is stateless. You cannot count things across multiple runs, maintain a running total, or remember what happened in the last execution. If you need to track "this user has filed 5 tickets today," you need ScriptRunner or an external system.
3. No AI or NLP classification
Rule matching is field-based: label equals, status is, component contains. There is no way to classify ticket text, detect intent, or route by content meaning. A ticket that says "I can't log in" gets routed the same way as one that says "login button missing on mobile" unless someone has already labeled them differently.
4. No multi-system orchestration
You cannot read from Salesforce and write to Jira in the same rule. You cannot pull data from your internal database to populate ticket fields. Any workflow that requires reading from a system outside Atlassian's ecosystem hits a wall.
5. No custom UI
Automation rules have no output surface beyond Jira. You cannot build a Slack modal, populate a dashboard, or create a report from automation rule output. The rule acts on Jira data, in Jira.
ScriptRunner vs Native Automation
ScriptRunner (by Adaptavist) is a Jira Marketplace app that adds Groovy scripting to the platform. It does not replace native automation — it extends it at the points where native rules run out.
What ScriptRunner adds that native automation lacks:
- Full HTTP client: make GET/POST calls to any API and use the response in your script
- Complex conditional logic: loops, counters, string manipulation, date arithmetic
- Database queries against Jira's internal database
- Scheduled scripts that run outside the rule engine
- Custom validators and conditions on issue transitions
ScriptRunner pricing (2026 market rates):
- 50 users: ~$180/month
- 100 users: ~$360/month
- 250 users: ~$600/month
- Scales with Jira user count
When to use ScriptRunner: you need to call an external API, calculate something the rule engine cannot express, or orchestrate across Jira projects in ways the native editor cannot handle.
When not to use ScriptRunner: if native automation covers the use case, use it. Groovy scripts are harder to maintain, require a developer to modify, and create a knowledge dependency in your team. Treat ScriptRunner as a scalpel, not a default.
Custom Integration Cost Table
When neither native automation nor ScriptRunner is sufficient — typically because the workflow spans Jira and a system outside the Atlassian ecosystem — a custom integration is the right answer.
| Integration | Typical cost |
|---|---|
| Jira → Slack rich notifications bot (formatted summaries, buttons, thread replies) | $4K–8K |
| AI ticket classifier and router (LLM-based category and assignee selection) | $8K–15K |
| Jira ↔ Salesforce or HubSpot two-way sync | $10K–20K |
| Full Atlassian ops automation (routing + SLA enforcement + Slack notifications + reporting) | $20K–40K |
Implementation Sequence
The most common mistake is building new automation on top of a broken foundation. Before creating anything new, audit what exists.
Step 1: Audit existing rules. In most Jira instances that have been in use for more than a year, 30–40% of automation rules are dead: they reference deleted components, trigger on issue types that no longer exist, or were built for a workflow that changed. Delete these first. Broken rules add noise and occasionally conflict with working ones.
Step 2: Implement the five highest-impact native rules. From the table above, pick the five that address your most frequent manual tasks. Configure, test with real tickets, run for two weeks before adding more.
Step 3: Measure for four weeks. Track time saved, errors introduced, and edge cases. Native automation rules frequently need a condition added (“only when assignee is empty”) after you see how they behave in production.
Step 4: Evaluate the remaining gaps. After four weeks, you have real data on what native automation is not covering. Some gaps are worth closing with ScriptRunner; others require a custom integration. The gap analysis at this point is grounded in observed behavior, not speculation.
Frequently Asked Questions
Is Atlassian Automation free?
The Free plan includes 500 rule runs per month. Standard gives 1,500 per month. Premium offers unlimited runs plus cross-project automation. For most teams under 20 people, Free or Standard is sufficient; Premium pays off at high ticket volume or complex cross-project workflows. If you are hitting the run limit, upgrading to Premium is almost always cheaper than the engineering time spent working around the limit.
What's the difference between Atlassian Automation and ScriptRunner?
Native Atlassian Automation uses a no-code rule editor with a defined set of triggers and actions. ScriptRunner adds Groovy scripting for complex logic, external API calls, and database access. ScriptRunner is a paid Marketplace app starting around $180/month; native automation is included with Jira. The key question: does your use case require an API call or conditional branching on response data? If yes, ScriptRunner. If no, stay native.
Can Atlassian Automation send messages to Slack?
Yes, via webhook. Native automation can POST a plain-text message to a Slack webhook URL. For rich messages with formatted ticket details, action buttons, and interactive elements (modals, replies in thread), you need a custom Slack bot that receives Jira webhook events and formats them before sending. The distinction matters: plain-text Slack messages are free to implement; rich interactive messages with custom logic are a custom development project.
How long does it take to set up Atlassian Automation?
The 10 highest-value native rules take 4–8 hours to configure and test properly. ScriptRunner scripts for common patterns: 1–3 days each. Custom integrations such as a Slack bot or CRM sync: 2–6 weeks depending on scope, the number of external systems involved, and how much existing Jira configuration needs to be understood before automation can safely touch it.
