.webp)
Jira Automation vs. ScriptRunner for JSM
From the archive
When should a JSM team use Jira Automation or ScriptRunner?
Start with Jira Automation when its triggers, conditions, and actions express the workflow clearly. Consider ScriptRunner when custom logic or integration requirements justify maintaining code. Confirm the feature exists in your Jira deployment: ScriptRunner Cloud and Data Center are different products with different limits.
- Routine routing, notifications, and status changes: try a native automation flow first.
- Specialized calculations or integrations: assess ScriptRunner against the APIs, permissions, and maintenance effort required.
- Dynamic request fields: check the supported fields and screens for the specific Behaviours product before designing the form.
Use Atlassian’s JSM automation guide alongside Adaptavist’s Cloud and Data Center feature comparison to make that choice.
Picture the moment.
Your service desk admin has been at it for three hours. They've got a new onboarding workflow in JSM. New hires submit a request, and depending on the department, the location, and whether the role requires a security clearance, the request needs to spawn three different kinds of work in three different projects, with different approvers, different SLAs, and different welcome packages. They've been wrestling with Jira Automation rules, building one branch, then another, then realizing the conditions don't quite chain the way they need them to.
Eventually they Slack me. "Can Avaratak help? I think Jira Automation has officially given up on me."
That is the point to compare the workflow design, the native automation options, and the extra control a script might provide. A script can make some logic easier to express, but it still needs testing, error handling, and an owner.
This blog is about that conversation.
A Quick Refresher
Jira Service Management is Atlassian's IT service management platform — the spiritual evolution of the old service desk, now a full-fledged ITSM tool with request management, incident management, change management, and Assets all baked in. We wrote a love letter to it earlier this year, and it remains one of the most under-appreciated jewels in the Atlassian portfolio.
ScriptRunner is Adaptavist’s family of tools for extending Jira with scripted logic and related features. Check the deployment and feature before choosing an approach: Cloud and Data Center are not interchangeable. In particular, Cloud Behaviours use JavaScript or TypeScript, while other scripting contexts use Groovy.
Together, they're a service desk power combo that's hard to beat.
The Complementary Truth Nobody Says Out Loud
Here's the honest framing I give every client.
Jira Automation is a sensible first choice for flows that its native triggers, conditions, and actions express clearly. Start there for routine assignment, notifications, and transitions, while checking your plan’s usage limits.
ScriptRunner becomes worth evaluating when a requirement needs custom logic, a supported scripted field, or an API interaction that is easier to maintain as code. Complexity alone does not prove that native automation cannot do the job; compare both approaches against the actual requirement.
These specialized requirements can have a large effect on the service experience. Choose the approach your team can explain, test, and support after the original author has moved on.
The right question isn't "Jira Automation or ScriptRunner?" The right question is "where does each one belong in our toolkit?"
Five Ways ScriptRunner Earns Its Keep on JSM
These are illustrative requirements to evaluate. Their implementation depends on your Jira deployment, app features, exposed APIs, and permissions.
Complex decision branching. The onboarding scenario I opened with? In Jira Automation, you'd be stitching together conditional branches that quickly become unreadable. In ScriptRunner, it's a single script that reads the department, location, and clearance fields, and creates the right child issues in the right projects with the right approvers. One source of truth. One place to debug.
SLA-aware escalation. Native SLAs in JSM are good. But what if you need to escalate a P1 ticket only when the assignee has been unresponsive for 60 minutes and the request has high VIP scoring and the customer is in a paid support tier? ScriptRunner can read all of that, decide, and act. The escalation that used to be a phone call at midnight becomes a quiet Slack ping to the on-call manager.
Custom post-functions. When a request is resolved, fire off a personalized email that includes a CSAT link tied to that customer's locale. When a change is approved, automatically generate the corresponding pull request in Bitbucket. When an incident is closed, write the post-mortem stub into Confluence with the right template and the right owner. These are the tiny workflow finishers that turn JSM from a queue into a polished service experience.
Scripted fields. Native custom fields are static. Scripted fields are alive. A refund-amount field that automatically converts to the customer's currency. A risk-score field that recomputes based on the affected services. A sentiment field that pulls from the linked customer success record. The data your team needs, available where they need it.
REST API integrations. Data Center’s custom REST Endpoints feature is not available in ScriptRunner for Jira Cloud. Cloud scripts can use supported APIs to interact with Jira and external systems. For an integration such as syncing customer records, establish the data contract, credentials, error handling, and rate limits before estimating the build.
What should you check before using Behaviours in JSM Cloud?
Adaptavist’s current supported fields and products matrix includes the JSM Request Create Portal. Support varies by field and action, so check the exact request type and field configuration you plan to use.
Pick one request form, identify the change you need, and test it in the supported interface. Validate required fields and fallback behavior before expanding to other request types.
The Avaratak Take
A few honest words from the trusted-advisor seat.
ScriptRunner is genuinely powerful, and that means it deserves real governance. I've seen Jira instances with 200+ ungoverned scripts, no documentation, no ownership, and a quietly ticking time bomb of "what does this even do?" If you're going to invest in ScriptRunner, invest in the practice around it: name your scripts, document them, assign owners, review them quarterly, and treat them like code — because they are.
Three practical recommendations we give clients adopting ScriptRunner on JSM.
Start with one specific gap. Keep existing native flows that work well. Evaluate ScriptRunner for one requirement that needs additional control, and compare the result with the maintenance cost of the script.
Pair scripts with knowledge. Every ScriptRunner workflow we deploy gets a corresponding Confluence page documenting what it does, why it exists, and who owns it. This habit alone will save your team weeks of forensic work two years from now.
Check Behaviours support. Audit the fields and request types you want to change, then test them against the current support matrix.
Worth Saying Out Loud
Most JSM teams discover ScriptRunner after they've spent days trying to force-fit Jira Automation into a use case it was never going to handle. We try to spare our clients that detour. The smart move is to know which tool to reach for from the start — and to have a partner who's seen enough JSM workflows to spot a difficult requirement before it eats your sprint.
If you're staring at a JSM workflow that just won't behave, that's exactly the conversation we love at Avaratak Consulting. Stop by avaratak.com and bring the workflow that's been giving you trouble. Odds are very good there's an elegant ScriptRunner answer waiting for it.