Hooks / Docs / The Console

The Console

Last updated 24/08/2026

The Console is the single authoring surface, structured as a four-step story:

When should it run? — pick the trigger. Event triggers show scoping pickers; schedules show the visual schedule builder; the JQL kind explains that the hook's name becomes its search.
What should it do? — write the script, start from one of eleven examples (filtered to your chosen trigger), or paste a JQL and generate a commented script around it.
Try it — Run, with Dry run, Run as, and event simulation.
Save it — name it and choose whether it goes live immediately.

What a script receives

Exactly three values: jira (the curated API below), console (captured logging), and context (the event payload for triggered hooks). Code is wrapped in an async function — top-level await and return work. Nothing else — no require, no process, no Forge SDK.

The jira.* API

Method	Description
`jira.myself()`	Current profile.
`jira.getIssue(key, fields?)`	Fetch one work item.
`jira.search(jql, maxResults?)`	JQL search (must be bounded — see Limits page).
`jira.addComment(key, text)`	Plain-text comment (auto-wrapped in ADF).
`jira.updateIssue(key, fields)`	Update fields.
`jira.transition(key, transitionId)`	Workflow transition by id.
`jira.forEachIssue(jql, fn)`	Paginate and call `fn` per item (5,000 cap inline — use a bulk job for more).
`jira.request(method, path, body?)`	Escape hatch to any Jira REST endpoint.

Dry run and Run as

Dry run suppresses every write — comments, updates, transitions, mutating jira.request calls — logging what would have been sent while reads run for real. Runs are badged DRY RUN. Run as: me executes a console run with your own permissions instead of the app's (saved hooks always run as the app). Simulate an event by typing a work-item key so context.event.issue.key is populated.