Jira

Manage issues in Jira

Triggers

On Alert Listen to alert created, acknowledged, closed, or deleted events in JSM Ops

On Incident Listen to incident created, updated, or deleted events in Jira Service Management

On Issue Listen to issue created, updated, or deleted events in Jira

On Issue Comment Listen to comment created, updated, or deleted events on Jira issues

Actions

Approve Workflow Approve or decline a Jira Service Management request approval

Create Alert Create a Jira Service Management Ops alert via the Alerts API

Create Heartbeat Create a Jira Service Management Operations heartbeat monitor

Create Incident Create a Jira Service Management incident via the Incidents API

Create Issue Create a new issue in Jira

Delete Alert Delete a Jira Service Management Ops alert by id

Delete Heartbeat Delete a Jira Service Management Operations heartbeat

Delete Incident Delete a Jira Service Management incident by issue id or issue key

Delete Issue Delete a Jira issue

Get Alert Fetch a Jira Service Management Ops alert by alert id

Get Incident Fetch a Jira Service Management incident by issue id or issue key

Get Issue Retrieve a Jira issue by its key

Get Workflow Get the Jira workflow bound to an issue, including its current status and reachable transitions

Ping Heartbeat Send a ping to a Jira Service Management Operations heartbeat

Transition Issue Move a Jira issue to a reachable workflow status

Update Alert Update, assign, add a note to, acknowledge, or close a Jira Service Management Ops alert

Update Heartbeat Update a Jira Service Management Operations heartbeat

Update Issue Update fields on a Jira issue

Instructions

SuperPlane connects to Jira with OAuth.

Click the Connect button with Client ID and Client Secret empty to see the steps for creating an Atlassian OAuth app.

On Alert

Trigger key: jira.onAlert

The On Alert trigger starts a workflow execution when an alert changes state in Jira Service Management Operations (Ops).

Use Cases

Escalation automation: Notify a channel or page someone when a new alert fires
Incident linkage: Open a Jira incident when a high-priority alert is created
Reporting: Track alert volume and acknowledgement time

Configuration

Team (optional): JSM Operations team to scope alerts to; leave empty to listen for alerts from every team
Events: Which alert events to listen for (Created, Acknowledged, Closed, Deleted)

Webhook Setup

This is provisioned automatically as a dedicated outgoing Webhook integration in JSM Ops for this trigger - unlike jira.onIssue, JSM Ops has no “one URL per connection” limit, so each jira.onAlert trigger gets its own registration, removed automatically when the trigger is deleted.

Requires a Premium or Enterprise Jira Service Management plan - Atlassian gates outgoing webhook integrations to those tiers, and requires the enableOpsFeatures option on this connection to be turned on (Settings tab), since it needs the JSM Ops OAuth scopes.

Output

Emits one event per matching alert webhook with:

action: created, acknowledged, closed, or deleted
alert: The alert (alertId, tinyId, alias, message, priority, tags, source, username)

Example Data

{
  "data": {
    "action": "created",
    "alert": {
      "alertId": "9e1c6a9e-1234-4a1a-8f1a-0a1b2c3d4e5f",
      "message": "CPU usage above 90% on payments-api",
      "priority": "P2",
      "source": "Datadog",
      "tags": [
        "production",
        "payments"
      ],
      "tinyId": "123"
    }
  },
  "timestamp": "2026-07-17T09:30:00Z",
  "type": "jira.alert"
}

On Incident

Trigger key: jira.onIncident

The On Incident trigger starts a workflow execution when an incident is created, updated, or deleted on a Jira Service Management service desk.

An incident is a Jira issue on a request type that belongs to the Incident management work category (the same request types jira.createIncident can open) - this trigger reuses the project-wide issue webhook every jira.onIssue trigger shares, and matches events to the request types you select here by their underlying issue type.

Use Cases

Incident response automation: Page a team or open a channel when a new incident is created
Status sync: Mirror incident updates into another tool
Reporting: Track incident volume and resolution over time

Configuration

Service Desk: The Jira Service Management service desk to listen for incidents on
Request Types: One or more incident request types on that service desk to listen for
Events: Which incident events to listen for (Created, Updated, Deleted)

Webhook Setup

This is provisioned automatically, sharing the same webhook registration jira.onIssue uses - see that trigger’s documentation for how Jira’s dynamic webhook registration works.

Output

Emits one event per matching incident webhook with:

action: created, updated, or deleted
issue: The full issue (id, key, self, fields)
user: The user who triggered the event
changelog: The list of changed fields (only present for updates)

Example Data

{
  "data": {
    "action": "created",
    "issue": {
      "fields": {
        "assignee": {
          "accountId": "5f8a1c2b3d4e5f6a7b8c9d0e",
          "displayName": "Alice Smith",
          "emailAddress": "alice@example.com"
        },
        "created": "2026-07-17T09:30:00.000+0000",
        "issuetype": {
          "name": "IT Help"
        },
        "labels": [
          "auth",
          "regression"
        ],
        "priority": {
          "name": "High"
        },
        "project": {
          "id": "10000",
          "key": "ENG",
          "name": "Engineering"
        },
        "reporter": {
          "accountId": "5f8a1c2b3d4e5f6a7b8c9d0f",
          "displayName": "Bob Jones",
          "emailAddress": "bob@example.com"
        },
        "status": {
          "name": "To Do",
          "statusCategory": {
            "key": "new",
            "name": "To Do"
          }
        },
        "summary": "Login page returns 500 on invalid password",
        "updated": "2026-07-17T09:30:00.000+0000"
      },
      "id": "10001",
      "key": "ENG-42",
      "self": "https://your-domain.atlassian.net/rest/api/3/issue/10001"
    },
    "user": {
      "accountId": "5f8a1c2b3d4e5f6a7b8c9d0f",
      "displayName": "Bob Jones",
      "emailAddress": "bob@example.com"
    }
  },
  "timestamp": "2026-07-17T09:30:00Z",
  "type": "jira.incident"
}

On Issue

Trigger key: jira.onIssue

The On Issue trigger starts a workflow execution when issue events occur in a Jira project.

Use Cases

Issue automation: Automate responses to new or updated Jira issues
Notification workflows: Send notifications when issues are created or updated
Sync workflows: Mirror Jira issues into other tools

Configuration

Project: The Jira project to listen for issue events in
Events: Which issue events to listen for (Created, Updated, Deleted)

Webhook Setup

This is provisioned automatically. Jira’s dynamic webhook registration API (POST /rest/api/3/webhook) only allows a single registered callback URL per OAuth connection, so SuperPlane registers one shared webhook per Jira integration - every jira.onIssue trigger on that connection listens through it, each matching only the events for its own configured project. The shared webhook is removed automatically once the last trigger using it is deleted.

Output

Emits one event per matching issue webhook with:

action: created, updated, or deleted
issue: The full issue (id, key, self, fields)
user: The user who triggered the event
changelog: The list of changed fields (only present for updates)

Example Data

{
  "data": {
    "action": "created",
    "issue": {
      "fields": {
        "assignee": {
          "accountId": "5f8a1c2b3d4e5f6a7b8c9d0e",
          "displayName": "Alice Smith",
          "emailAddress": "alice@example.com"
        },
        "created": "2026-07-17T09:30:00.000+0000",
        "issuetype": {
          "name": "Bug"
        },
        "labels": [
          "auth",
          "regression"
        ],
        "priority": {
          "name": "High"
        },
        "project": {
          "id": "10000",
          "key": "ENG",
          "name": "Engineering"
        },
        "reporter": {
          "accountId": "5f8a1c2b3d4e5f6a7b8c9d0f",
          "displayName": "Bob Jones",
          "emailAddress": "bob@example.com"
        },
        "status": {
          "name": "To Do",
          "statusCategory": {
            "key": "new",
            "name": "To Do"
          }
        },
        "summary": "Login page returns 500 on invalid password",
        "updated": "2026-07-17T09:30:00.000+0000"
      },
      "id": "10001",
      "key": "ENG-42",
      "self": "https://your-domain.atlassian.net/rest/api/3/issue/10001"
    },
    "user": {
      "accountId": "5f8a1c2b3d4e5f6a7b8c9d0f",
      "displayName": "Bob Jones",
      "emailAddress": "bob@example.com"
    }
  },
  "timestamp": "2026-07-17T09:30:00Z",
  "type": "jira.issue"
}

On Issue Comment

Trigger key: jira.onIssueComment

The On Issue Comment trigger starts a workflow execution when a comment is added, edited, or removed on an issue in a Jira project.

Use Cases

Customer response workflows: React when a customer comments on a service desk request
Notification workflows: Send notifications when someone comments on an issue
Sync workflows: Mirror Jira comments into other tools

Configuration

Project: The Jira project to listen for comment events in
Events: Which comment events to listen for (Created, Updated, Deleted)
Content Filter (optional): Regex pattern to filter comments by content, e.g. urgent to only trigger on comments containing “urgent”. A comment with no extractable text never matches when a filter is set.

Webhook Setup

This is provisioned automatically, sharing the same webhook registration jira.onIssue uses - see that trigger’s documentation for how Jira’s dynamic webhook registration works.

Output

Emits one event per matching comment webhook with:

action: created, updated, or deleted
comment: The comment (id, body, author, updateAuthor)
issue: The full issue the comment belongs to (id, key, self, fields)

Example Data

{
  "data": {
    "action": "created",
    "comment": {
      "author": {
        "accountId": "5f8a1c2b3d4e5f6a7b8c9d0e",
        "displayName": "Alice Smith",
        "emailAddress": "alice@example.com"
      },
      "body": "Thanks for the update, looking into this now.",
      "id": "10019",
      "updateAuthor": {
        "accountId": "5f8a1c2b3d4e5f6a7b8c9d0e",
        "displayName": "Alice Smith",
        "emailAddress": "alice@example.com"
      }
    },
    "issue": {
      "fields": {
        "issuetype": {
          "name": "Bug"
        },
        "project": {
          "id": "10000",
          "key": "ENG",
          "name": "Engineering"
        },
        "status": {
          "name": "To Do",
          "statusCategory": {
            "key": "new",
            "name": "To Do"
          }
        },
        "summary": "Login page returns 500 on invalid password"
      },
      "id": "10001",
      "key": "ENG-42",
      "self": "https://your-domain.atlassian.net/rest/api/3/issue/10001"
    }
  },
  "timestamp": "2026-07-17T09:30:00Z",
  "type": "jira.issueComment"
}

Approve Workflow

Component key: jira.approveWorkflow

The Approve Workflow component approves or declines a Jira Service Management request approval.

Use Cases

Automated approval routing: submit a JSM approval decision after external checks pass
Escalation handling: decline requests when a SuperPlane workflow detects a failed precondition
Audit context: add a customer request comment before submitting the approval decision

Configuration

Issue Key: JSM request issue key, for example ITSM-123.
Decision: Approve or decline.
Approval Selector: Choose the latest pending approval or pick a specific one from the list.
Approval: The pending approval to decide. Required when picking a specific approval.
Comment: Optional public customer request comment posted before the approval decision.

Output

Returns the updated approval payload from Jira Service Management.

Notes

Requires the API token’s user to be in the approver list.
This component only works on Jira Service Management customer requests, not standard Jira issues.

Example Output

{
  "data": {
    "approvers": [
      {
        "approver": {
          "accountId": "5b10a2844c20165700ede21g",
          "displayName": "Alice Example",
          "emailAddress": "alice@example.com"
        },
        "approverDecision": "approved"
      }
    ],
    "completedDate": {
      "iso8601": "2026-01-19T13:15:00+0000",
      "jira": "2026-01-19T13:15:00.000+0000"
    },
    "finalDecision": "approved",
    "id": "1",
    "name": "Manager approval"
  },
  "timestamp": "2026-01-19T13:15:00Z",
  "type": "jira.approval"
}

Create Alert

Component key: jira.createAlert

The Create Alert component opens a new alert on Jira Service Management.

Use Cases

Monitoring integrations: Raise an alert from metrics or logs
Automation: Drive on-call notifications from workflows

Configuration

Message (required): Alert message text.
Description, Note, Alias, Entity, Source (optional): Standard Ops alert fields.
Priority (optional): Typically P1–P5; choose “Don’t set” to omit.
Tags / Actions (optional): Lists of strings.
Responders / Visible to (optional): Rows with id and type (team, user, escalation, or schedule).
Extra properties (optional): JSON object merged into the API extraProperties field.

Output

After the Ops API accepts create, SuperPlane waits for asynchronous processing via the alerts request status API, then GETs the resulting alert.

The payload matches Get Alert (full Ops alert JSON: id, message, status, etc.).

If Jira delays processing beyond the polling window the step fails — use Get Alert with the Ops request id noted in logs if Atlassian exposes it.

Notes

Requires Jira Service Management Ops permissions and API scopes for alerts on your Atlassian site; the integration stores your site cloud id during sync.

Example Output

{
  "data": {
    "acknowledged": false,
    "actions": [],
    "alias": "alias",
    "count": 2,
    "createdAt": "2026-01-19T12:00:00Z",
    "description": "description",
    "entity": "an entity",
    "extraProperties": {},
    "id": "439aa701-7cd6-4549-8992-d06650561222-1779166598474",
    "integrationName": "",
    "integrationType": "",
    "lastOccuredAt": "2026-01-19T12:00:00Z",
    "message": "message",
    "owner": "",
    "priority": "P2",
    "responders": [],
    "seen": false,
    "services": [],
    "snoozed": false,
    "source": "source",
    "status": "open",
    "tags": [
      "test-tag"
    ],
    "tinyId": "4",
    "updatedAt": "2026-01-19T12:00:00Z"
  },
  "timestamp": "2026-01-19T12:00:00Z",
  "type": "jira.alert.created"
}

Create Heartbeat

Component key: jira.createHeartbeat

The Create Heartbeat component registers a new heartbeat in Jira Service Management Operations.

Use Cases

Cron monitoring: Register an expected ping interval for scheduled jobs or agents
Infrastructure checks: Create heartbeats when provisioning monitored systems
Automation setup: Pair with Ping Heartbeat in workflows that report liveness

Configuration

Team: JSM Operations team that owns the heartbeat
Name (required): Unique heartbeat name within the team
Interval (required): How often a ping is expected (minimum 1)
Interval unit: minutes, hours, or days
Enabled: Whether monitoring is active (defaults to enabled)
Description, alert message, alert tags, alert priority: Optional expiration alert settings

Output

Returns the created heartbeat object from the JSM Operations API, including name, interval, intervalUnit, enabled, and status.

Notes

Requires Jira Service Management Operations (Premium) with heartbeats enabled on your site.
Re-sync the Jira integration so SuperPlane has your Atlassian cloud id.

Example Output

{
  "data": {
    "alertMessage": "The alert has been raised",
    "alertPriority": "P3",
    "alertTags": [
      "tag1"
    ],
    "description": "my new heartbeat",
    "enabled": true,
    "interval": 1,
    "intervalUnit": "minutes",
    "name": "DNS checker",
    "ownerTeamId": "b071f2e7-2159-4110-aa25-7718b2713ed5",
    "status": "Pending"
  },
  "timestamp": "2026-01-19T12:00:00Z",
  "type": "jira.heartbeat.created"
}

Create Incident

Component key: jira.createIncident

The Create Incident component opens a new incident in Jira Service Management.

Use Cases

Alert-driven incidents: Create an incident from a monitoring or ticketing workflow
Cross-tool orchestration: Open a JSM incident when another system reports an outage
Responder assignment: Pass responders and other fields supported by your service desk

Configuration

Service desk: Choose a Jira Service Management service desk (from your site via the JSM API)
Request type: Choose a request type on that service desk (lists after a service desk is selected)
Summary (required): Short title for the incident; sent as the Jira summary field (Jira requires this). You can set this directly, or supply summary only via Additional fields.
Description (optional): Plain text stored as Jira description (Atlassian Document Format).
Due date (optional): Jira duedate (use your site date format, typically YYYY-MM-DD).
Priority (optional): Jira priority name (for example Medium).
Impact (optional): Impact level from your Jira request type (options load after service desk and request type are selected).
Urgency (optional): Urgency level from your Jira request type (options load after service desk and request type are selected).
Original estimate (optional): Jira timetracking.originalEstimate (for example 2h, 1d).
Custom fields (optional): List of Jira field ids with JSON values—for affected services, pending reason, or any customfield_*; the value must be valid JSON (object or string) as Jira expects for that field type.
Additional fields (optional): JSON object merged into the API fields map (same pattern as other integrations such as Honeycomb Fields JSON).
Update (optional): JSON object for the Incidents API update property.
Alert IDs (optional): List of alert id strings to associate with the incident.

Output

Returns id (numeric issue id), key (e.g. ITSM-30), and self (issue REST URL) from the create response.

Notes

Requires a Jira Cloud site with Jira Service Management and a synced SuperPlane Jira integration (cloud id is resolved automatically).
Request types must belong to Jira’s Incident management work category; other request types (for example service requests) are hidden from the picker when Jira returns a practice field on request types. If your site uses an unrecognized practice value, contact support with a sample from GET /rest/servicedeskapi/servicedesk/{serviceDeskId}/requesttype/{requestTypeId} with expand=practice.
Field ids such as responders are site-specific; use Custom fields or Additional fields with values that match your JSM configuration.

Example Output

{
  "data": {
    "id": "10050",
    "key": "ITSM-30",
    "self": "https://your-domain.atlassian.net/rest/api/3/issue/10050"
  },
  "timestamp": "2026-01-19T12:00:00Z",
  "type": "jira.incident.created"
}

Create Issue

Component key: jira.createIssue

The Create Issue component creates a new issue in Jira.

Use Cases

Task creation: Automatically create tasks from workflow events
Bug tracking: Create bugs from error detection systems
Feature requests: Generate feature request issues from external inputs

Configuration

Project: The Jira project to create the issue in
Issue Type: The type of issue (scoped to the chosen project)
Summary: The issue summary/title
Description: Optional description text
Assignee: Optional Jira user to assign the issue to
Status: Optional initial status. Jira always creates issues in the workflow’s initial state, so when this is set the component executes a transition immediately after create. The status must be reachable via a transition from the initial state.

Output

Returns the created issue including:

id: The issue ID
key: The issue key (e.g. PROJ-123)
self: API URL for the issue
fields: Full issue fields after any status transition

Example Output

{
  "data": {
    "fields": {
      "assignee": {
        "accountId": "5b10a2844c20165700ede21g",
        "displayName": "Alice Example",
        "emailAddress": "alice@example.com"
      },
      "created": "2026-01-19T12:00:00.000+0000",
      "issuetype": {
        "name": "Bug"
      },
      "labels": [
        "backend",
        "p1"
      ],
      "priority": {
        "name": "High"
      },
      "project": {
        "id": "10000",
        "key": "PROJ",
        "name": "Proj"
      },
      "reporter": {
        "accountId": "5b10ac8d82e05b22cc7d4ef5",
        "displayName": "Bob Example"
      },
      "status": {
        "name": "To Do",
        "statusCategory": {
          "key": "new",
          "name": "To Do"
        }
      },
      "summary": "Investigate timeout on checkout flow",
      "updated": "2026-01-19T12:00:00.000+0000"
    },
    "id": "10001",
    "key": "PROJ-123",
    "self": "https://your-domain.atlassian.net/rest/api/3/issue/10001"
  },
  "timestamp": "2026-01-19T12:00:00Z",
  "type": "jira.issue"
}

Delete Alert

Component key: jira.deleteAlert

The Delete Alert component removes an alert from Jira Service Management.

Deletion is processed asynchronously like other mutating Ops operations.

Configuration

Alert: Pick the Ops alert to delete from the integration resource list.

Output

Includes the API acknowledgement (requestId, etc.) and deleted: true for workflow convenience.

Example Output

{
  "data": {
    "alertId": "439aa701-7cd6-4549-8992-d06650561222-1779166598474",
    "deleted": true,
    "requestId": "82e59857-e111-44a3-9f72-013783b94f52",
    "result": "Request will be processed"
  },
  "timestamp": "2026-01-19T12:00:00Z",
  "type": "jira.alert.deleted"
}

Delete Heartbeat

Component key: jira.deleteHeartbeat

The Delete Heartbeat component removes a heartbeat from Jira Service Management Operations.

Use Cases

Decommissioning: Remove heartbeats when systems are retired
Test cleanup: Delete heartbeats created during automation tests
Lifecycle management: Tear down monitoring when workflows are disabled

Configuration

Team: Team that owns the heartbeat
Heartbeat: Name of the heartbeat to delete

Output

Confirms deletion with deleted set to true and the name of the removed heartbeat.

Notes

Requires Jira Service Management Operations with heartbeats enabled.
Deletion is permanent; recreate the heartbeat if needed.

Example Output

{
  "data": {
    "deleted": true,
    "name": "DNS checker"
  },
  "timestamp": "2026-01-19T12:00:00Z",
  "type": "jira.heartbeat.deleted"
}

Delete Incident

Component key: jira.deleteIncident

The Delete Incident component removes an incident from Jira Service Management.

Use Cases

Automated cleanup: Remove incidents created during tests or erroneous automation
Lifecycle workflows: Delete when a duplicate or mistaken incident is closed upstream

Configuration

Project (optional): Narrows the issue picker to one Jira project (up to 500 most recently updated issues in that project).
Issue: The incident issue to delete (issue key from Jira search).

Output

Confirms deletion with deleted set to true.

Example Output

{
  "data": {
    "deleted": true
  },
  "timestamp": "2026-01-19T12:00:00Z",
  "type": "jira.incident.deleted"
}

Delete Issue

Component key: jira.deleteIssue

The Delete Issue component permanently removes an issue from Jira.

Use Cases

Cleanup: remove placeholder or duplicate issues created by automated flows
CRUD completion: pair with create/update flows for full lifecycle management

Configuration

Project: The Jira project the issue belongs to
Issue Key: The issue key (e.g. PROJ-123)
Delete Subtasks: Also delete the issue’s subtasks (Jira returns an error if subtasks exist and this is false)

Output

Returns the deleted issue’s id and key, plus deleted: true.

Example Output

{
  "data": {
    "deleted": true,
    "id": "10001",
    "key": "PROJ-123"
  },
  "timestamp": "2026-01-19T13:00:00Z",
  "type": "jira.issueDeleted"
}

Get Alert

Component key: jira.getAlert

The Get Alert component returns full alert details from Jira Service Management.

Configuration

Alert: Pick a recent Ops alert from the integration resource list (same as Update / Delete Alert).

Output

Payload type jira.alert.fetched with the alert object (message, status, priority, responders, tags, etc.).

Example Output

{
  "data": {
    "acknowledged": false,
    "actions": [],
    "alias": "alias",
    "count": 3,
    "createdAt": "2026-01-19T12:00:00Z",
    "description": "description",
    "entity": "entity",
    "extraProperties": {},
    "id": "20bfb3c4-ded8-4123-b9d2-c7840a0d4589-1779115726660",
    "integrationName": "",
    "integrationType": "",
    "lastOccuredAt": "2026-01-19T12:00:00Z",
    "message": "message",
    "owner": "",
    "priority": "P2",
    "responders": [],
    "seen": false,
    "services": [],
    "snoozed": false,
    "source": "source",
    "status": "open",
    "tags": [],
    "tinyId": "3",
    "updatedAt": "2026-01-19T12:00:00Z"
  },
  "timestamp": "2026-01-19T12:00:00Z",
  "type": "jira.alert.fetched"
}

Get Incident

Component key: jira.getIncident

The Get Incident component returns incident details from Jira Service Management.

Use Cases

Enrichment: Load incident DTO after an issue webhook or workflow step
Status checks: Read priority, status, responders, and affected services from JSM

Configuration

Project (optional): When set, the issue picker lists issues in that project (by project key), paged from Jira search (up to 500, most recently updated first). Leave empty to list issues updated in roughly the last 90 days across projects you can access (same cap and ordering).
Issue: Choose an issue by key (from Jira search). The stored value is the issue key; numeric ids still work when they are saved as the issue reference.

Output

Payload type jira.incident.fetched with the incident object returned by Atlassian (summary, reporter, priority, status, responders, etc.).

Example Output

{
  "data": {
    "priority": {
      "id": "1",
      "name": "High"
    },
    "summary": "Example incident"
  },
  "timestamp": "2026-01-19T12:00:00Z",
  "type": "jira.incident.fetched"
}

Get Issue

Component key: jira.getIssue

The Get Issue component retrieves a Jira issue and its fields for downstream routing and inspection.

Use Cases

Routing decisions: inspect status, assignee, labels, or priority before branching
Escalation context: include issue details in notifications or downstream tickets
Cross-tool sync: enrich workflows that mirror Jira state into other systems

Configuration

Project: The Jira project the issue belongs to
Issue Key: The issue key (e.g. PROJ-123)
Expand: Optional comma-separated Jira expand values, such as renderedFields,names

Output

Returns the Jira issue object including id, key, self and the full fields map.

Example Output

{
  "data": {
    "fields": {
      "assignee": {
        "accountId": "5b10a2844c20165700ede21g",
        "displayName": "Alice Example",
        "emailAddress": "alice@example.com"
      },
      "created": "2026-01-19T12:00:00.000+0000",
      "issuetype": {
        "name": "Bug"
      },
      "labels": [
        "backend",
        "p1"
      ],
      "priority": {
        "name": "High"
      },
      "project": {
        "id": "10000",
        "key": "PROJ",
        "name": "Proj"
      },
      "reporter": {
        "accountId": "5b10ac8d82e05b22cc7d4ef5",
        "displayName": "Bob Example"
      },
      "status": {
        "name": "In Progress",
        "statusCategory": {
          "key": "indeterminate",
          "name": "In Progress"
        }
      },
      "summary": "Investigate timeout on checkout flow",
      "updated": "2026-01-19T12:30:00.000+0000"
    },
    "id": "10001",
    "key": "PROJ-123",
    "self": "https://your-domain.atlassian.net/rest/api/3/issue/10001"
  },
  "timestamp": "2026-01-19T12:00:00Z",
  "type": "jira.issue"
}

Get Workflow

Component key: jira.getWorkflow

The Get Workflow component returns the Jira workflow that governs a given issue.

Use Cases

State-machine introspection: see every status in the workflow plus where the issue is right now
Routing decisions: branch on which transitions are currently reachable before running transitionIssue
Operator dashboards: render the workflow as a graph next to the issue

Configuration

Project: The Jira project the issue belongs to.
Issue Key: Jira issue key, for example PROJ-123.

Output

Returns:

workflowName and workflowSchemeName — the workflow scheme assigned to the project and the workflow it routes the issue’s type to.
currentStatus / currentStatusId — where the issue is now.
statuses — every status the workflow defines (with isCurrent set on the current one).
availableTransitions — transitions reachable from the issue’s current state, each with the transition id, name, and target status.

Notes

Resolving the bound workflow goes issue → project + issue type → workflow scheme → workflow. Team-managed (next-gen) projects don’t expose a workflow scheme; in that case workflowName and statuses are empty but currentStatus and availableTransitions are still populated.
The availableTransitions list reflects workflow rules, conditions, and the calling user’s permissions — it is exactly what Jira would offer in the issue view.

Example Output

{
  "data": {
    "availableTransitions": [
      {
        "id": "21",
        "name": "Stop progress",
        "toStatus": "To Do",
        "toStatusId": "10001"
      },
      {
        "id": "31",
        "name": "Resolve",
        "toStatus": "Done",
        "toStatusId": "10003"
      }
    ],
    "currentStatus": "In Progress",
    "currentStatusId": "10002",
    "issueKey": "PROJ-123",
    "issueType": "Task",
    "projectKey": "PROJ",
    "statuses": [
      {
        "category": "TODO",
        "id": "10001",
        "name": "To Do"
      },
      {
        "category": "IN_PROGRESS",
        "id": "10002",
        "isCurrent": true,
        "name": "In Progress"
      },
      {
        "category": "DONE",
        "id": "10003",
        "name": "Done"
      }
    ],
    "workflowName": "Software Simplified Workflow",
    "workflowSchemeId": "101010",
    "workflowSchemeName": "Default workflow scheme"
  },
  "timestamp": "2026-01-19T12:00:00Z",
  "type": "jira.workflow"
}

Ping Heartbeat

Component key: jira.pingHeartbeat

The Ping Heartbeat component reports that a monitored system is alive.

Use Cases

Scheduled jobs: Ping at the end of a cron workflow so JSM detects missed runs
Deploy pipelines: Confirm a service is up after deployment
Agent check-ins: Let automation prove an external process completed

Configuration

Team: Team that owns the heartbeat
Heartbeat: Heartbeat name to ping (from the team’s heartbeat list)

Output

Returns the API message (for example “PONG - Heartbeat received”).

Notes

Requires Jira Service Management Operations with heartbeats enabled.
The heartbeat must already exist (use Create Heartbeat or configure it in JSM).

Example Output

{
  "data": {
    "message": "PONG - Heartbeat received"
  },
  "timestamp": "2026-01-19T12:00:00Z",
  "type": "jira.heartbeat.pinged"
}

Transition Issue

Component key: jira.transitionIssue

The Transition Issue component moves a Jira issue through its workflow.

Use Cases

Automated triage: move issues into the next workflow status after a SuperPlane event
Cross-tool state sync: mirror status changes from incident or deployment systems
Resolution automation: close issues with a transition-scoped resolution and comment

Configuration

Project: Optional Jira project used to narrow the status picker.
Issue Key: Jira issue key, for example PROJ-123.
Target Status: Status to move the issue to. It must be reachable from the issue’s current status.
Comment: Optional transition comment.
Resolution: Optional Jira resolution name to set during the transition.

Output

Returns the refreshed Jira issue after the transition.

Notes

Jira does not allow direct status writes. This component finds an available transition whose target status matches the requested status.
Workflow conditions and validators still apply.

Example Output

{
  "data": {
    "fields": {
      "project": {
        "id": "10000",
        "key": "PROJ",
        "name": "Proj"
      },
      "resolution": {
        "name": "Done"
      },
      "status": {
        "name": "Done",
        "statusCategory": {
          "key": "done",
          "name": "Done"
        }
      },
      "summary": "Investigate timeout on checkout flow",
      "updated": "2026-01-19T13:00:00.000+0000"
    },
    "id": "10001",
    "key": "PROJ-123",
    "self": "https://your-domain.atlassian.net/rest/api/3/issue/10001"
  },
  "timestamp": "2026-01-19T13:00:00Z",
  "type": "jira.issue"
}

Update Alert

Component key: jira.updateAlert

The Update Alert component runs updates on alerts on Jira Service Management.

Toggle each optional subsection you need; untouched sections are not sent to Jira.

Optional updates

Description → updates alert description
Message → updates alert message
Priority → updates alert priority (omit with “Don’t set”)
Assignment → assigns the alert to a Jira user (Atlassian account ID from the assignee picker)
New note → adds a new note
Update existing note → updates existing note with nested note id + note text
Acknowledge alert → acknowledges alert
Close alert → closes alert

After updates, SuperPlane polls the last asynchronous Ops response (when applicable) and emits a fresh GET alert payload like Get Alert.

Example Output

{
  "data": {
    "acknowledged": true,
    "actions": [],
    "alias": "alias",
    "count": 3,
    "createdAt": "2026-01-19T12:00:00Z",
    "description": "description",
    "entity": "entity",
    "extraProperties": {},
    "id": "20bfb3c4-ded8-4123-b9d2-c7840a0d4589-1779115726660",
    "integrationName": "",
    "integrationType": "",
    "lastOccuredAt": "2026-01-19T12:00:00Z",
    "message": "message",
    "owner": "",
    "priority": "P5",
    "responders": [],
    "seen": false,
    "services": [],
    "snoozed": false,
    "source": "source",
    "status": "open",
    "tags": [],
    "tinyId": "3",
    "updatedAt": "2026-01-19T12:00:00Z"
  },
  "timestamp": "2026-01-19T12:00:00Z",
  "type": "jira.alert.updated"
}

Update Heartbeat

Component key: jira.updateHeartbeat

The Update Heartbeat component changes settings on an existing JSM Operations heartbeat.

Use Cases

Tune intervals: Adjust expected ping frequency after operational changes
Enable/disable monitoring: Turn heartbeats on or off from automation
Alert tuning: Update expiration alert message, tags, or priority

Configuration

Team and Heartbeat (required): Identify the heartbeat to update
Optional fields use toggles: only enabled fields are sent to the Jira API
Heartbeat name cannot be changed (create a new heartbeat instead)

Output

Returns the updated heartbeat object from the JSM Operations API.

Notes

Enable at least one optional field toggle before saving or running the node.
Requires Jira Service Management Operations with heartbeats enabled.

Example Output

{
  "data": {
    "alertMessage": "The alert has been raised",
    "alertPriority": "P3",
    "alertTags": [
      "tag1"
    ],
    "description": "my new heartbeat",
    "enabled": true,
    "interval": 5,
    "intervalUnit": "minutes",
    "name": "DNS checker",
    "ownerTeamId": "b071f2e7-2159-4110-aa25-7718b2713ed5",
    "status": "Responsive"
  },
  "timestamp": "2026-01-19T12:00:00Z",
  "type": "jira.heartbeat.updated"
}

Update Issue

Component key: jira.updateIssue

The Update Issue component updates fields on an existing Jira issue.

Use Cases

Automated triage: change status, priority, or assignee when a workflow processes the issue
Cross-tool sync: mirror state from another system into Jira
Bulk relabeling: apply labels based on workflow inputs

Configuration

Project: The Jira project the issue belongs to
Issue Key: The issue key (e.g. PROJ-123)
Summary, Description, Issue Type, Assignee, Priority, Labels: Optional fields to update. At least one must be supplied.
Notify Users: Whether to send notification emails (defaults to Jira’s behaviour)

Output

Returns the updated Jira issue as fetched after the update.

Example Output

{
  "data": {
    "fields": {
      "assignee": {
        "accountId": "5b10a2844c20165700ede21g",
        "displayName": "Alice Example"
      },
      "issuetype": {
        "name": "Bug"
      },
      "labels": [
        "backend",
        "p1",
        "in-review"
      ],
      "priority": {
        "name": "Medium"
      },
      "project": {
        "id": "10000",
        "key": "PROJ",
        "name": "Proj"
      },
      "status": {
        "name": "In Review"
      },
      "summary": "Investigate timeout on checkout flow (updated)",
      "updated": "2026-01-19T12:45:00.000+0000"
    },
    "id": "10001",
    "key": "PROJ-123",
    "self": "https://your-domain.atlassian.net/rest/api/3/issue/10001"
  },
  "timestamp": "2026-01-19T12:45:00Z",
  "type": "jira.issue"
}