When to Use
- PR merge triggers "In Review" status: When a GitHub pull request is opened for a branch named with a Jira key, a workflow calls
getTransitions to find the "In Review" transition ID, then calls executeTransition to move the issue to the review state automatically — eliminating manual status updates.
- Deployment pipeline status sync: When a CI/CD pipeline successfully deploys a release, a post-deploy workflow transitions all issues tagged with the release fix version from "Ready for Release" to "Released", stamping the deployment timestamp on each.
- Auto-close resolved incidents: A scheduled workflow queries incidents resolved more than 72 hours ago that are still in "Resolved" status, and executes the "Close" transition on each to maintain a clean active-issue count.
- Approval-gated workflow progression: A Human-In-Loop approval node waits for manager sign-off. On approval, the workflow calls
executeTransition to advance the change request from "Pending Approval" to "Approved for Implementation".
- Automated QA gating: When a test suite passes, a post-CI webhook triggers a workflow that transitions the linked Jira story from "In Progress" to "QA Ready", notifying the QA team via Slack.
Configuration
Connection
| Field | Required | Description |
Host | Required | Jira instance base URL. Example: https://acmecorp.atlassian.net |
Email | Required | Atlassian account email. Example: automation@acmecorp.com |
ApiToken | Required | API token from Atlassian security settings. Store in Credentials Manager. |
Operation Fields
| Field | Required | Description |
IssueKey | Required | The key of the issue to transition. Example: PROJ-123. |
TransitionId | Required | The numeric transition ID obtained from issue/getTransitions. Example: "41". Do not hardcode this value — resolve dynamically per execution. |
Fields | Optional | JSON object of fields required by the transition screen. Only needed if the transition has a screen with mandatory fields (e.g. a "Resolution" field required on closing). Format follows Jira field format. |
Sample Configuration
Close a resolved issue with a resolution field (typical for Done/Close transitions):
{
"resource": "issue",
"operation": "executeTransition",
"Host": "https://acmecorp.atlassian.net",
"Email": "automation@acmecorp.com",
"ApiToken": "{{ $credentials.jiraApiToken }}",
"IssueKey": "{{ $json.issueKey }}",
"TransitionId": "{{ $output.getTransitions.transitions.find(t => t.name === 'Done').id }}",
"Fields": {
"resolution": { "name": "Fixed" }
}
}
Validation Errors
| Error Code | Cause |
VAL_MISSING_ISSUE_KEY | IssueKey is empty or null. |
VAL_MISSING_TRANSITION_ID | TransitionId is empty or null. |
TRANSITION_NOT_VALID | The transition ID does not exist or is not valid from the issue's current status. Call getTransitions to confirm availability. |
MISSING_REQUIRED_FIELDS | The transition screen requires fields that were not supplied in Fields. |
ISSUE_NOT_FOUND | No issue exists with the given key, or insufficient access. |
AUTH_FAILED | Invalid credentials or expired API token. |
Output Fields
| Field | Type | Description |
status | string | "success" or "error" |
issueKey | string | Key of the transitioned issue. Example: "PROJ-123" |
newStatus | string | Name of the status the issue has moved to. Example: "Done", "In Review". |
resource | string | Always "issue" |
operation | string | Always "executeTransition" |
Sample Output
{
"status": "success",
"issueKey": "OPS-347",
"newStatus": "Done",
"resource": "issue",
"operation": "executeTransition"
}
Expression Reference
| Expression | Type | Example Value | Use |
{{ $output.executeTransition.newStatus }} | string | "Done" | Confirm the target status was reached |
{{ $output.executeTransition.issueKey }} | string | "OPS-347" | Include in post-transition Slack notification |
{{ $output.executeTransition.status }} | string | "success" | Guard downstream steps on transition confirmation |
Node Policies & GuardRails
- Always resolve transition IDs dynamically: Use a preceding
issue/getTransitions call and filter by name. Never embed numeric transition IDs directly in configuration — they change when Jira workflows are edited.
- Validate transition availability: After calling
getTransitions, confirm the target transition name exists in the returned array before calling executeTransition. Provide a meaningful error path if the transition is unavailable from the current state.
- Supply required transition screen fields: Some transitions (especially "Close" and "Resolve") have mandatory fields like
resolution. Check with your Jira admin which transitions require screen fields, and always supply them in the Fields parameter.
- Post-transition verification: After executing a transition, optionally call
issue/get to confirm the status_val matches the expected new status. This guards against silent failures in complex workflow configurations.
Workflow Examples
Example 1 — PR Merge Auto-Transition to "In Review"
// Step 1: GitHub webhook — PR opened
// Step 2: Extract Jira key from branch (e.g. feature/PROJ-123-payment-fix)
// Step 3: issue/getTransitions
{
"IssueKey": "{{ $json.extractedKey }}"
}
// Step 4: Function — resolve transition ID
// const t = $output.getTransitions.transitions.find(t => t.name === "In Review");
// Step 5: issue/executeTransition
{
"IssueKey": "{{ $json.extractedKey }}",
"TransitionId": "{{ $output.findTransition.id }}"
}
Example 2 — Auto-Close Resolved Incidents Older Than 72h
// Step 1: ScheduledTrigger (daily)
// Step 2: issue/getAll
{
"Jql": "project = OPS AND status = Resolved AND updated <= -72h ORDER BY updated ASC",
"Limit": 50
}
// Step 3: Loop over issues
// Step 4 per issue: issue/getTransitions { IssueKey: $loopItem.key }
// Step 5: Resolve "Close" transition ID
// Step 6: issue/executeTransition
{
"IssueKey": "{{ $loopItem.key }}",
"TransitionId": "{{ $output.closeTransitionId }}",
"Fields": { "resolution": { "name": "Done" } }
}