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."

And I smile, because I know exactly what conversation we're about to have. It's the one where I introduce them to ScriptRunner, and a problem that took three frustrated hours becomes a single, elegant Groovy script that runs in milliseconds.

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 the Adaptavist-built, Groovy-powered Swiss Army knife that lives on top of Jira (and JSM specifically). It's been the most popular app on the Atlassian Marketplace for years, and for good reason. ScriptRunner gives JSM admins direct access to logic the native UI doesn't expose — custom post-functions, listeners, scripted fields, scheduled jobs, REST endpoints, and (finally, by end of March 2026) Behaviours for JSM Cloud.

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 handles roughly 80% of the automation needs you'll have on JSM. It's no-code, it's included with your subscription, and Atlassian keeps making it more capable. For the bread-and-butter rules — auto-assigning tickets, sending notifications, transitioning statuses — Jira Automation is genuinely all you need.

ScriptRunner handles the other 20%. The branching logic that has too many conditions to express in a no-code rule. The integration with the third-party identity provider that needs custom REST work. The scripted field that calculates cost-of-delay across three different exchange rates. The scheduled job that audits stale change requests every Tuesday at 2 AM and quietly closes the ones that have been ignored.

That 20% is where the most valuable automation hides. And it's usually the part that defines whether your JSM feels like a generic ticket queue or a thoughtful service experience.

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

Let me get specific.

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. ScriptRunner's REST endpoints let JSM talk to the rest of your stack in either direction. Pull customer records from Salesforce when a support ticket is created. Push incident data to PagerDuty when severity changes. Sync change requests with your asset CMDB. The integrations that would have required a developer sprint become a thoughtful afternoon for a JSM admin who knows their Groovy.

What's New for 2026

The headline coming out of Adaptavist's roadmap is that Behaviours support for JSM Cloud is shipping by the end of March 2026. If you've used Behaviours on Jira Software, you already know why this is exciting. If not, here's the elevator pitch: Behaviours let you dynamically control fields on a form — show, hide, mark required, set values, validate inputs — based on what the user has already entered. On a JSM portal, that turns clunky, intimidating request forms into smart, conversational experiences that only ask for what's actually relevant.

This one is worth planning for now. The teams that have their request types and field libraries cleaned up will be ready to roll Behaviours out on day one. The teams that haven't will spend a quarter untangling things first. Front-load the cleanup.

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 the impossible 20%. Don't try to rebuild your existing Jira Automation rules in Groovy just because you can. Find the one workflow that's been bugging your team because Jira Automation can't quite express it, and let ScriptRunner solve that. Win small, win specific.

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.

Plan for Behaviours. Audit your JSM request types and forms now, so you're ready to make them dynamic and intelligent the moment Behaviours lands.

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 the impossible 20% 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.