Anyone who has rolled out Jira Service Management knows this stage: the system works, tickets flow in, but technicians still manually assign issues, change priorities and send notifications that Jira should be sending on its own. Automation in Jira has been around for a long time, in the cloud it runs within plan limits, yet many teams use it only modestly. This article changes that.
How Jira Automation works: triggers, conditions, actions
Every automation rule in Jira has three elements. Understanding this structure is a prerequisite for building rules that actually work, rather than generating false notifications or infinite loops.
Trigger
The event that fires the rule. It can be an issue event (creation, status change, field update, comment), a time event (scheduled trigger: hourly, daily, weekly) or an external event (incoming webhook, script alert). In Jira Service Management ITSM-specific triggers also exist: approaching SLA breach, customer reply, portal change.
Condition
A condition filters which issues meet the criteria. Without a condition the rule fires for every event matching the trigger, which is often not what you want. You can combine conditions logically (AND/OR), check field values via JQL, verify membership in a project, queue or user group.
Action
What the rule does: change a field, assign, change status, send an email or webhook, create a sub-task, comment, create a new issue in another project. Actions can be chained: one rule can execute 5 actions sequentially. In Jira Cloud the monthly limit is counted on rule runs, not individual actions. A rule with 5 actions executed 100 times uses 100 units, not 500.
Rule 1: Auto-assign based on ticket category
A technician manually assigns every inbound ticket. This is the first thing to automate. The rule checks the component or issue type and assigns the right technician or rotates among queue members.
Configuration
- Trigger: Issue created
- Condition: Issue matches:
component = "Network"ORissuetype = "Hardware failure" - Action: Assign issue to Choose a specific user or Balance workload (JSM Premium)
Rule 2: SLA breach alert - escalation before the deadline
This is the most important rule in any JSM-based help desk. Instead of reacting to a breached SLA, you react 30 minutes earlier, when there is still time to intervene. More on configuring queues and SLA levels in JSM in a separate guide: SLA in Jira Service Management: queues and escalations.
Configuration
- Trigger: SLA threshold breached to Time to first response to 30 minutes before breach
- Condition: Status is
OpenORIn Progress(do not react to already closed) - Action 1: Send email to assignee + team lead
- Action 2: Add comment: "Notice: first-response SLA expires in 30 minutes."
- Action 3 (optional): Edit issue to Priority: High (if lower)
Rule 3: Ticket escalation on priority change
When someone bumps a ticket priority to Critical or Blocker, the manager should know about it immediately, not from an email two hours later. This rule sends a notification and creates a sub-task for the manager.
Configuration
- Trigger: Field value changed to Priority
- Condition: New value of Priority is
CriticalORBlocker - Action 1: Send email to the "IT Manager" role on the project
- Action 2: Create sub-task "Escalation: review incident {{issue.key}}"
Rule 4: Auto-close of inactive tickets
Classic problem: a ticket in "Waiting for customer" status for a week, the customer did not reply, the help desk did not close it. The queue grows, metrics lie. This rule fires daily in the morning and tidies up.
Configuration
- Trigger: Scheduled, daily at 8:00
- Condition: JQL:
status = "Waiting for customer" AND updated <= -5d - Action 1: Add comment: "We are closing this ticket after 5 days without a reply. You can reopen it at any time."
- Action 2: Transition issue to Closed
Rule 5: Linked issues - block resolve when there are open dependencies
In engineering projects an issue can be accidentally closed while its blockers are still open. This rule catches it and reverts to the previous status with a comment explaining why.
Configuration
- Trigger: Issue transitioned to status "Done" or "Resolved"
- Condition: Issue matches:
issue in linkedIssues("is blocked by") AND linkedIssues("is blocked by").status != Done - Action 1: Transition issue to the previous status (In Progress)
- Action 2: Add comment: "Cannot close, {{issue.links.outwardIssue.key}} is still open."
Rule 6: Notify the customer of a status change
The customer does not know what is happening with their ticket, so they call, write on Teams, corner the technician in the hallway. This rule eliminates the problem at the source: the customer gets an email on every status change, without involving the team.
Configuration
- Trigger: Issue transitioned
- Condition: Issue matches:
issuetype in standardIssueTypes()(exclude sub-tasks) - Action: Send email to Reporter, Subject: "Update on {{issue.key}}: {{issue.status}}", body with
{{issue.summary}}and a link to the portal
Rule 7: Automatic labels from ticket content
Users do not categorize tickets, they type "no internet" and hit Send. This rule scans description and subject, looks for keywords and adds a relevant label, enabling proper reporting.
Configuration (one block per category)
- Trigger: Issue created
- Condition: Advanced compare:
{{issue.summary}} contains "network" OR {{issue.description}} contains "internet" OR {{issue.description}} contains "VPN" - Action: Edit issue to Labels: add
category-network - Duplicate the block for each category: printer, password, laptop, software
Rule 8: Webhook from an external monitoring system
Monitoring caught a problem: the technician should have a ticket in 10 seconds, not 10 minutes. An incoming webhook in Jira Automation turns a monitoring alert into a complete ITSM ticket without any intermediate integration.
Configuration
- Trigger: Incoming webhook, copy the URL, paste into the monitoring system as the webhook URL
- Action 1: Create issue, Project: IT-Ops, Type: Incident, Summary:
{{webhookData.alert_name}}, Priority:{{webhookData.severity}} - Action 2: Assign issue to the on-call technician
- No condition: every monitoring alert generates a ticket
Rule 9: Reminder for a ticket without a comment after 24h
A ticket went to a technician, the technician had other priorities and it has been sitting untouched. This rule acts like a gentle tap on the shoulder: "hey, you have something to do".
Configuration
- Trigger: Scheduled, hourly
- Condition: JQL:
assignee is not EMPTY AND status = "In Progress" AND updated <= -1d AND comment <= -1d - Action: Send email to Assignee: "Reminder: {{issue.key}} had no activity for 24h. Current SLA status: {{issue.sla.timeToResolution.remainingTime}}"
Rule 10: Weekly report - automatic digest for the manager
The manager spends half an hour every Friday filtering Jira and compiling a report for the board. This rule does it automatically, with metrics, links to open tickets and information on SLA breaches.
Configuration
- Trigger: Scheduled, weekly, Friday 16:00
- Action: Send email to the manager, content with a
{{#issues.count}}block - In the email: number of open tickets, number of tickets with SLA breaches in the week, list of the 5 oldest unresolved
- Requires: Smart Values + Lookup issues as a helper action (Standard+ plan)
Jira Automation vs Power Automate vs n8n: comparison table
Jira is not the only option for automating ITSM processes. The table below compares the three most popular tools in the context of help desk and IT operations, without the marketing gloss.
| Criterion | Jira Automation | Power Automate | n8n |
|---|---|---|---|
| Integration with Jira | Native, zero latency | Connector (2-5 sec. latency) | Jira node (API, needs configuration) |
| Pricing model | Included in the Jira plan | Per-flow or per-user (from 15 USD/mo) | Self-hosted: free; Cloud: from 20 USD/mo |
| External integrations | Webhook in/out, limited | 500+ connectors (Teams, SAP, Salesforce) | 400+ nodes, full flexibility |
| Configuration difficulty | Low (GUI no-code) | Medium (requires MS 365) | High (JSON, API, self-hosting) |
| JSM SLAs and queues | Full native support | None (API only) | None (API only) |
| Debugging | Audit log per rule | Run history (30 days) | Execution log (full history) |
| When to pick | ITSM contained in Jira | Cross-system with M365 | DevOps pipeline, full control |
If your help desk lives in Jira and you need ITSM process automation, Jira Automation is the default choice. You do not pay extra, you do not configure external connections, rules have full access to every field and metadata. Power Automate is in play when processes cross the Jira boundary and reach Teams, SharePoint or Dynamics. n8n is an option for DevOps teams that want full control and accept a higher onboarding bar. If you are thinking about connecting Jira with an ERP or MES system, see also the article on Jira integration with ERP and MES step by step.
Related articles
ManageEngine vs Jira Service Management: which ITSM to pick in 2026? NinjaOne RMM: complete guide for IT managers CMDB instead of Excel: how to manage IT assets professionally Oxari workflow automation: how to configure ITSM rulesFAQ
Does Jira Automation work in Jira Software and Jira Service Management at the same time?
Yes, with one important difference. Jira Software offers per-project and global automation. Jira Service Management (JSM) adds ITSM-specific rules: SLA handling, customer portal, queues and escalation levels. Rules can also be created cross-project, linking the two products into one pipeline.
How many automation rules can I have on a Cloud plan?
Automation limits in Jira Cloud depend on the plan and change over time as Atlassian evolves the billing model. In general: lower plans have a monthly execution pool tied to the product, in higher plans the limits are accrued per user. Always confirm the current values in the official Atlassian documentation. Importantly, Jira counts rule executions, not individual actions: a rule with 5 actions executed 100 times uses 100 units, not 500.
How does Jira Automation differ from Power Automate for ITSM processes?
Jira Automation runs natively inside Jira: zero latency, full access to every field and metadata on the issue, no per-run costs. Power Automate shines as a cross-system tool (Teams, SharePoint, Outlook, SAP). For ITSM processes contained within Jira, Jira Automation wins on speed and simplicity. When a flow links Jira with the Microsoft 365 ecosystem, Power Automate is the better choice.
How do I debug a Jira automation rule that is not working?
Open Automation > pick the rule > Audit log tab. Every rule run is logged with a timestamp, outcome (success/error) and the exact reason for failure, for example "Condition not met: Priority != High". You can also click Manual trigger and test the rule on a specific issue without waiting for the trigger.
Can Jira automation modify issues from external systems via webhook?
Yes. Jira Automation supports the "Incoming webhook" trigger: an external system (for example Zabbix monitoring, a PagerDuty alert, a form) sends an HTTP POST to a unique URL and the automation rule performs actions in Jira: creates an issue, changes status, assigns a technician, adds a comment. This is the most powerful entry point for integration without extra iPaaS connections.
We will configure Jira Automation for your team
We will analyze your help desk processes and roll out the first 5 automation rules in a single workshop. No theory, only ready rules running in your environment.
Book a workshopWant to deploy Jira or ManageEngine automation in your help desk? See what an implementation looks like