Scriptbox and ScriptRunner Compared
If you know ScriptRunner, most of Scriptbox will feel familiar: a script console, listeners, scheduled jobs, scripted fields, behaviours and workflow extensions. The differences are in where scripts run, what language you write, and a handful of places where Forge draws a different line than Data Center did.
This page maps one onto the other honestly — including what Scriptbox cannot do.
Scriptbox section tabs across the app bar
## The two differences that shape everything
- Where scripts run → Scriptbox runs your scripts inside its own Forge function, on Atlassian's runtime, with no egress. ScriptRunner for Jira Cloud is a Connect app; at the time of writing, its scripts run on the vendor's own hosting. See Runs on Atlassian and Data Handling.
- What you write → Scriptbox scripts are TypeScript, with a typed Jira SDK and autocomplete for 557 endpoints. ScriptRunner's Cloud scripts are mostly Groovy (its Cloud Behaviours are JavaScript). See Typed Jira SDK and Autocomplete.
Feature by feature
| ScriptRunner feature |
Scriptbox equivalent |
What is different |
| Script Console |
Console tab |
Run as Me or The app; 15-second budget per run |
| Script Listeners |
Listeners tab |
The ten supported events are fixed at deploy time; a listener narrows them, never widens them. Runs as the app. |
| Scheduled Jobs |
Scheduled tab |
Standard 5-field cron, per-job timezone. Nothing fires faster than every five minutes, and a job runs near its time. Quartz syntax (seconds, ?, L, W, #) is rejected with a translation. |
| Scripted Fields |
Fields tab |
Real Jira custom fields (number, text, date, date and time). The script answers for a batch of issues and runs as the app. |
| Behaviours |
Behaviours tab |
Built on the same Jira UI modifications platform. The script runs in the browser inside a QuickJS sandbox, and cannot call Jira. |
| Workflow post functions |
"Scriptbox: Run a script" rule |
Runs after the transition, asynchronously, as the app |
| Workflow validators and conditions |
Script validator, expression validator, expression condition |
Conditions and expression validators are Jira expressions, not scripts |
| — |
Jira Automation action |
A "Run a Scriptbox script" step inside an automation rule |
| Groovy migration |
Migrate tab and the Scriptbox Assistant |
Assesses and converts Groovy into TypeScript drafts for you to review |
What Scriptbox does not do
Stated up front, rather than discovered later:
- REST endpoints, fragments and custom JQL functions have no Scriptbox equivalent. The Migration Analysis marks them as such and says what would be needed.
- No outbound HTTP. A script reaches your Jira site only — no Confluence, no Bitbucket, no third-party APIs.
- No attachment uploads or binary content. Everything crossing the sandbox boundary is JSON, so multipart uploads fail.
- No impersonating a named user. Scheduled, event-driven, field, workflow and automation runs have no user and always use the app identity.
- No custom validation messages from behaviours. Jira's UI modifications cannot raise them; use a script validator on the transition instead.
- Jira Service Management calls currently fail.
jira.serviceDesk is exposed, but the app does not yet request Service Management scopes, so Jira refuses those calls.
- Searching on scripted fields is unverified. Per Atlassian's documentation the values should be searchable with JQL; Scriptbox has not yet confirmed that on a live site, or whether a value can be shown as a results column.
Moving scripts across
Start with Migration Analysis: drop in your Groovy files, and each one is classified, assessed against what Scriptbox can actually do, and — where it can be — converted and checked before you see it. Then follow Converting Groovy Scripts.