JIra Connector

Overview

The Jira connector integrates Xurrent iPaaS runbooks with Jira Cloud. It creates, updates, searches and transitions issues, manages their comments and attachments, looks up and creates users, and starts workflows when an issue or a comment is created or updated.

Status: The connector is published as Jira Connector.

The connector calls the Jira Cloud platform REST API v3 for its outbound actions, consumes Jira webhooks for its real-time triggers, and searches Jira on a schedule for its polling triggers.

It provides:

• Issues — create, update, read, transition and assign issues, and read their change history.
• Searching — find issues with simple filters or with a JQL query.
• Comments — add, edit and list the comments of an issue.
• Attachments — upload, download and list the attachments of an issue.
• Users — look up users, list assignable users and create users.
• Schema and REST — read the fields an issue takes, and call any Jira Cloud REST API path.
• Triggers — start a workflow in real time when an issue or a comment is created or updated, or on a schedule with the issues created or changed since the last check.

Prerequisites

To use this connector, you need:

• A Jira Cloud site, for example acme.atlassian.net. Jira Data Center, Jira Server and Jira Service Management are not supported.
• An Atlassian account with the Jira permissions the actions need (see Jira permissions), and an API token of that account:
  • Create the token at id.atlassian.com → Security → API tokens. Copy it at creation time; it is not shown again.
  • An API token expires 1 to 365 days after it is created. Replace it on the connection before that date.
• For the real-time triggers: a classic API token of a user with the Administer Jira permission. Jira refuses scoped and service-account tokens for webhooks.

Authentication

The connector uses HTTP Basic authentication: the Atlassian account email as the user name and the API token as the password. No OAuth consent flow is needed.

Field	Value
Jira site	The host of your Jira Cloud site, for example acme.atlassian.net. Enter the full host; a bare site name such as acme fails.
Atlassian account email	The email of the account the API token belongs to.
API token	The API token, stored as a secret.
Default project	Optional. Used when an action leaves its Project empty. The connection test checks that the account can open it. Save the site, email and token first, then pick a project.

The connection test reads the account behind the token and reports the site and the account it connected as. When the token expires or is revoked, every job on the connection fails until a new token is entered.

Token types

Token	Actions	Polling triggers	Real-time triggers
Classic API token of a user with Administer Jira	Yes	Yes	Yes
Classic API token of any other user	Yes	Yes	No
Scoped API token, or a service account token	Yes	Yes	No

A scoped token needs read:jira-user for the connection test, read:jira-work to check the Default project or read the project list, and the scopes of the actions it runs.

For automation that should not depend on one person, use a service account: give it access to the projects it works in and enter its email and one of its API tokens. A service account has scoped tokens only, so it runs every action and the polling triggers, but not the real-time triggers.

Jira permissions

Jira checks the permissions of the connection account on each project. The required permission depends on which trigger and actions you use:

Trigger / Action	Permission
New/Updated Issue (real-time), New/Updated Comment (real-time)	Administer Jira (classic token) and Browse Projects
New Issue, Updated Issue	Browse Projects
Create Issue	Create Issues
Update Issue	Edit Issues
Update Issue Status	Transition Issues (and Add Comments for its Comment)
Assign User to Issue	Assign Issues
Get Issue / Search Issues / Search Issues by JQL / Get Changelog of an Issue / Get Issue Schema	Browse Projects
Create Comment	Add Comments
Update Comment	Edit Own Comments, or Edit All Comments for the comments of other users
Get Issue Comments	Browse Projects
Upload Attachment	Create Attachments
Download Attachment / Get Issue Attachments	Browse Projects
Get User Details	Browse users and groups
Search Assignable Users	Assign Issues or Browse users and groups
Create User	Organization admin with Administer Jira
Execute Jira REST API Action	Whatever the called path needs; Jira checks it when the request runs

Identifiers

• Issues are named by key (KAN-12) or ID (10042). Moving an issue to another project changes its key and keeps its ID, so a runbook that must survive a move stores the ID.
• Users are named by account ID. Jira Cloud does not identify users by name or email; use Get User Details to turn an email or a name into an account ID.
• Projects are named by key or ID. An action that leaves Project empty uses the connection's Default project.
• Fields are named by field ID. Custom field IDs, such as customfield_10234, differ per Jira site; Get Issue Schema lists them.

Triggers

This connector provides two real-time triggers and two polling triggers. In a solution with more than one Jira connection, the triggers use the first one.

New/Updated Issue (real-time)

Starts a workflow the moment an issue is created or updated in one Jira project, through a Jira webhook.

Permission required: classic API token of a user with Administer Jira; Browse Projects on the project.

Setting up the webhook

• Promoting the runbook registers the webhook in Jira. Promoting fails when the account cannot open the project or the project has no such issue type.
• Each promote checks that the webhook is still enabled, signed, filtered on the project and sending the picked events, and registers it again when it is not.
• The webhook does not expire. A Jira site holds at most 100 webhooks.

Removing the trigger

Deprovision the trigger (the pause button) before you delete its runbook. Deprovisioning deletes the webhook in Jira, while deleting the trigger, the runbook or the solution leaves it behind. Delete such a webhook in Jira under System → WebHooks.

Delivery behavior

• Signed events: Jira signs each event. An event without a valid signature, or sent more than a day ago, is dropped.
• Duplicates: Jira can send the same event more than once, and iPaaS does not drop repeats. Every copy of one event has the same Deduplication ID, so a workflow that creates records or sends mail can skip a repeat.
• Concurrency: When the runbook's Concurrency limit drops an event because an earlier job still runs, iPaaS asks Jira to send it again, and Jira tries up to five more times over about an hour. For long jobs use the concurrency limit None.
• Outages: When every delivery fails for 30 minutes, Jira tries each event only once afterwards, so events can be lost.
• Description: The description is read from Jira as plain text when the event arrives, so a later edit can show in it. When the issue was deleted or the account cannot see it, Description is empty and Text unavailable reason is not_visible. When the read fails, Description holds the text that came with the event and the reason is fetch_failed.

Input Parameters

Parameter	Type	Required	Default	Description
Project	string	Yes	—	The Jira project to watch.
Issue type	string	No	—	Watch only this issue type. Empty watches every issue type.
Fire on	array	Yes	Created, Updated	Start a workflow for new issues, changed issues, or both.

Output

The issue with the same fields as Get Issue, plus:

Field	Type	Description
Event	string	jira:issue_created or jira:issue_updated.
Event type	string	What changed, for example issue_assigned.
Changed fields	array	Every field the event changed, with its old and new value and ID.
Changed by	object	The account ID, display name and email of the user who made the change.
Text unavailable reason	string	not_visible or fetch_failed, as described above. Empty when the description was read.
Timestamp	integer	When Jira sent the event, in milliseconds.

New/Updated Comment (real-time)

Starts a workflow the moment a comment is added or edited on an issue in one Jira project, through a Jira webhook. Setting up, removing and delivery work as for New/Updated Issue (real-time).

Permission required: classic API token of a user with Administer Jira; Browse Projects on the project.

The Comment body is read from Jira as plain text when the event arrives. When the comment was deleted or is limited to a role or group the account is not in, Comment body is empty and Text unavailable reason is not_visible.

Input Parameters

Parameter	Type	Required	Default	Description
Project	string	Yes	—	The Jira project to watch.
Issue type	string	No	—	Watch only comments on issues of this type. Empty watches every issue type.
Fire on	array	Yes	Created, Updated	Start a workflow for new comments, edited comments, or both.

Output

The comment with the same fields as Create Comment, plus Event (comment_created or comment_updated), Last edited by, Text unavailable reason, Timestamp, and the issue's key, ID, browse URL, summary, status, priority, issue type, project key and assignee. Read the rest of the issue with Get Issue.

New Issue

Starts a workflow on a schedule with the issues created in one Jira project since the last check. One run gets all the new issues one check finds, and a check that finds none starts nothing.

Permission required: Browse Projects

Polling behavior

• Settle delay: Jira search can take minutes to show a new or changed issue, so a check looks only at issues created or changed more than five minutes ago. A test issue shows up a few minutes late.
• Volume: One check reads up to 500 issues, and the next check goes on from there.
• Rate limits: When Jira limits the rate or is briefly unavailable, the check does not wait; it delivers what it already read, and the next check reads the rest.
• Concurrency: The trigger moves on only once iPaaS has started the job, so issues dropped by the Concurrency limit come again with a later check. When one check's issues cannot be delivered in three checks in a row, the trigger logs their keys and goes on after them.
• Promotion: The trigger keeps its place when the runbook is promoted again. A changed project or issue type starts again from five minutes before the promotion.
• Designer runs: A designer run shows the issues the next check would find, and the next check still delivers them.

Removing the trigger

Deprovision (the pause button) stops the checks. Deleting or replacing the trigger leaves its schedule running and each check then fails, so deprovision first.

Input Parameters

Parameter	Type	Required	Default	Description
Project	string	Yes	—	The Jira project to watch.
Issue type	string	No	—	Watch only this issue type (an issue type ID). Empty watches every issue type.
Check every (minutes)	integer	Yes	5	The minutes between two checks (minimum 1).

Output

Issues (array) — each issue with the fields of Get Issue except Comment count and Expanded; its Fields leave out the description. Read the list with the Flow connector's Loop action.

Updated Issue

Starts a workflow on a schedule with the issues changed in one Jira project since the last check. A new issue counts as changed, and an issue changed several times between two checks comes once. Inputs, outputs and behavior are the same as New Issue.

Permission required: Browse Projects

Actions

Issues

Create Issue

Creates an issue in a Jira project through the create issue API.

Permission required: Create Issues

In Description, a blank line starts a new paragraph, *bold* and _italic_ are formatted, and lines starting with "- " become a bulleted list. Use Description (ADF) for richer content. Put any other field in Additional fields, keyed by field ID. Jira returns only the ID, key and API URL of the new issue.

Input Parameters

Parameter	Type	Required	Default	Description
Project	string	No	Default project	Pick a project, or give a project key or ID.
Issue type	string	Yes	—	Pick one, or give an issue type name such as Task, or its ID.
Summary	string	Yes	—	The issue title.
Description	string	No	—	Plain text with the simple formatting described above.
Description (ADF)	object	No	—	A pre-built Atlassian Document Format object. Takes precedence over Description.
Priority	string	No	—	Pick one, or give a priority name or ID.
Assignee account ID	string	No	—	The account ID of the assignee.
Reporter account ID	string	No	—	The account ID of the reporter.
Labels	array	No	—	Labels to set.
Components	array	No	—	Component names.
Due date	date	No	—	The due date.
Parent issue key	string	No	—	Required by Jira for a sub-task.
Additional fields	object	No	—	Other fields keyed by field ID, for example {"customfield_10234": "value"}.

Output

Issue ID, Issue key, API URL and Browse URL of the new issue.

Update Issue

Changes fields on an existing issue through the edit issue API.

Permission required: Edit Issues

Only the fields you map are sent; unmapped fields stay as they are. A mapped Description, Assignee account ID, Priority, Labels, Components or Due date that is empty clears that field. Labels and Components replace the whole list. Jira returns no issue, so read the new state with Get Issue.

Input Parameters

Issue ID or key (required), then any of Summary, Description, Description (ADF), Priority, Assignee account ID, Reporter account ID, Labels, Components, Due date and Additional fields, as in Create Issue.

Output

Issue key or Issue ID (whichever was given) and Updated (boolean).

Update Issue Status

Moves an issue to another status through one of its workflow transitions, through the transition issue API.

Permission required: Transition Issues (Add Comments for the Comment)

Pick the transition from the list, which shows the transitions open to the issue typed into Issue ID or key. Or give a transition ID or name; a name is matched without regard to case. Transition IDs differ between workflows, so a runbook that has to travel gives the transition name.

Input Parameters

Parameter	Type	Required	Default	Description
Issue ID or key	string	Yes	—	The issue to move.
Transition	string	Yes	—	Pick one, or give a transition ID or name.
Fields	object	No	—	Values the transition screen needs, keyed by field ID, for example {"resolution": {"name": "Done"}}.
Comment	string	No	—	Added to the issue after the move. When Jira does not add it, the job fails and the issue keeps its new status.

Output

Issue key or Issue ID, Transition ID and Transitioned (boolean).

Assign User to Issue

Sets the assignee of an issue, replacing the one it had, through the assign issue API.

Permission required: Assign Issues

Input Parameters

Parameter	Type	Required	Default	Description
Issue ID or key	string	Yes	—	The issue to assign.
Assignee account ID	string	Unless Unassign is on	—	The account ID of a user who can be assigned issues in the project. -1 hands the issue to the project's default assignee.
Unassign	boolean	No	false	Removes the assignee. Assignee account ID is ignored.

Output

Issue key or Issue ID, Assignee account ID, Unassigned (boolean) and Sent to the project default assignee (boolean).

Get Issue

Reads one issue by its key or ID, through the get issue API.

Permission required: Browse Projects

By default it reads the summary, description, status, priority, issue type, project, assignee, reporter, dates, resolution, labels, components, attachments and the number of comments. Name other fields in Fields, or turn on All fields. The description comes back as plain text. Read the comments with Get Issue Comments.

Input Parameters

Parameter	Type	Required	Default	Description
Issue ID or key	string	Yes	—	The issue to read.
Fields	array	No	—	Field IDs to read instead of the default set, for example customfield_10234.
All fields	boolean	No	false	Read every field of the issue.
Expand	array	No	—	Extra parts to ask Jira for, for example renderedFields, changelog, transitions. Returned in Expanded.

Output

Issue fields: issue ID, issue key, API URL, browse URL, summary, description, status, status category, priority, issue type, issue type ID, project key, assignee, reporter, created, updated, resolution, resolution date, labels, components, attachments, comment count, Fields (every field read, as Jira returns it) and Expanded.

Get Changelog of an Issue

Lists the change history of an issue, oldest first, one page per run, through the get changelogs API.

Permission required: Browse Projects

Input Parameters

Issue ID or key (required), Page size (default 50, maximum 100) and Page token (see Paging).

Output

Entries (array) — each with entry ID, author, created, and Changed fields: field, field ID, old value, new value, and the old and new IDs where the field holds an ID. Plus Next page token and Is last page.

Searching

Paging

Search Issues, Search Issues by JQL, Get Changelog of an Issue, Get Issue Comments and Search Assignable Users return one page per run. Steps placed inside them run once per page. To go on in a later run, map Next page token into Page token. A search page token expires after 7 days.

Search Issues

Finds the issues of one project that match the filters you fill, most recently updated first, through the issue search API. No JQL is needed.

Permission required: Browse Projects

An issue must match every filter you fill, and an empty filter narrows nothing. Jira can take a few seconds to find an issue that just changed.

Input Parameters

Parameter	Type	Required	Default	Description
Project	string	No	Default project	The project to search.
Issue type	string	No	—	Only issues of this type.
Status	string	No	—	Status name or ID, for example In Progress.
Assignee account ID	string	No	—	Only issues assigned to this user.
Label	string	No	—	Only issues with this label.
Created after / Created before	datetime	No	—	Only issues created in this range.
Updated after / Updated before	datetime	No	—	Only issues updated in this range.
Page size	integer	No	50	How many issues one page holds (maximum 100).
Page token	string	No	—	A Next page token from an earlier run. Empty starts at the first page.

Output

Issues (array) — each with issue ID, issue key, browse URL, summary, status, priority, assignee and updated. Read the rest with Get Issue. Plus JQL (the query that ran, which Search Issues by JQL can take further), Next page token and Is last page.

Search Issues by JQL

Finds issues with a JQL query, one page per run, through the issue search API.

Permission required: Browse Projects

The query needs at least one restriction, such as project = KAN, because Jira refuses a query without one. Jira does not report how many issues match. To read back an issue you just wrote, use Get Issue.

Input Parameters

Parameter	Type	Required	Default	Description
JQL	string	Yes	—	For example project = KAN AND status != Done ORDER BY created DESC.
Fields	array	No	—	Field IDs to read. Defaults to the fields of the Jira issue list.
All fields	boolean	No	false	Read every field of each issue.
Expand	array	No	—	For example names, schema or changelog. With changelog, Jira returns at most 40 changes per issue; Get Changelog of an Issue returns them all.
Page size / Page token	—	No	50	As in Search Issues.

Output

Issues (array, same fields as Get Issue), Expanded (field names and schemas when Expand asks for them), Next page token and Is last page.

Comments

Create Comment

Adds a comment to an issue, through the add comment API.

Permission required: Add Comments

In Body, a blank line starts a new paragraph, *bold* and _italic_ are formatted, and lines starting with "- " become a bulleted list. Use Body (ADF) for links, mentions or other rich content.

Input Parameters

Parameter	Type	Required	Default	Description
Issue ID or key	string	Yes	—	The issue to comment on.
Body	string	No	—	Plain text with the simple formatting described above.
Body (ADF)	object	No	—	A pre-built Atlassian Document Format object. Takes precedence over Body.
Visibility type	string	No	—	role or group. Give both visibility fields, or neither for a comment everyone who can see the issue can read.
Visibility value	string	No	—	The role or group name, for example Administrators.

Output

Comment fields: comment ID, API URL, comment body (plain text), author, created, updated, and visibility (type, value, identifier).

Update Comment

Replaces the body of an existing comment, through the update comment API. The comment keeps its author, and keeps its visibility unless you give a new one.

Permission required: Edit Own Comments, or Edit All Comments for the comments of other users

Input Parameters

Issue ID or key (required), Comment ID (required), then Body, Body (ADF), Visibility type and Visibility value, as in Create Comment.

Output

The comment fields, as in Create Comment.

Get Issue Comments

Lists the comments of an issue, one page per run, through the get comments API. Each body comes as plain text. A comment limited to a role or a group is listed only when the connection account belongs to it.

Permission required: Browse Projects

Input Parameters

Parameter	Type	Required	Default	Description
Issue ID or key	string	Yes	—	The issue to read.
Order by	string	No	created	created or +created is oldest first, -created is newest first.
Page size / Page token	—	No	50	See Paging.

Output

Comments (array, same fields as Create Comment), Next page token and Is last page.

Attachments

Upload Attachment

Attaches one file to an issue, through the add attachment API.

Permission required: Create Attachments

File name, Content and Content type take the outputs of Download Attachment as they are, so a file can be copied from one issue to another. Before it sends the file, the action checks that the site accepts attachments and that the file fits the site's size limit.

Input Parameters

Parameter	Type	Required	Default	Description
Issue ID or key	string	Yes	—	The issue to attach the file to.
File name	string	Yes	—	Include the extension, for example report.csv.
Content	base64	Yes	—	The file as base64 text. An empty text uploads an empty file.
Content type	string	No	Detected	Detected from the file name when empty, for pdf, png, jpg, gif, svg, webp, json, xml, csv, txt and zip; any other file goes as application/octet-stream.

Output

Attachments (array). Attachment object fields: attachment ID, file name, size, content type, created, author.

Download Attachment

Downloads one attachment by its ID, through the get attachment content API. The file comes back as base64 text, with its name, content type and size.

Permission required: Browse Projects

The outputs map straight into Upload Attachment. Get the attachment ID from Get Issue Attachments, Get Issue or Upload Attachment. A file over 3 MB (3,145,728 bytes), the limit of one runbook step, is refused before it is downloaded.

Input Parameters

Attachment ID (string, required).

Output

Field	Type	Description
File name	string	The file name, such as report.pdf.
Content	base64	The file as base64 text.
Content type	string	The media type of the file, such as application/pdf.
Size	integer	The size of the file in bytes.

Get Issue Attachments

Lists the attachments of an issue without downloading them. Give an attachment ID to Download Attachment to get the file.

Permission required: Browse Projects

Input Parameters

Issue ID or key (string, required).

Output

Issue ID, Issue key and Attachments (array, same fields as Upload Attachment).

Users

Get User Details

Reads one Jira user, by account ID or by a name or email address, through the users API.

Permission required: Browse users and groups

Give Account ID or Query, not both. A query must lead to exactly one active user; no match, or several, fails the job. A query that is one email address finds only the user with exactly that address. Any other query matches when each of its words starts a word of the display name or email, so jo smi finds Jo Smith. Email address is empty unless the user's profile shows it.

Input Parameters

Parameter	Type	Required	Default	Description
Account ID	string	One of the two	—	The account ID of the user.
Query	string	One of the two	—	A full email address, or the start of words in a display name, for example jo smi.

Output

User fields: account ID, display name, email address, active, account type, time zone.

Search Assignable Users

Lists the users who can be assigned issues of a project, or of one issue, one page per run.

Permission required: Assign Issues or Browse users and groups

Give Issue ID or key or Project, not both; when both are empty, the Default project is used. Jira looks at no more than the first 1,000 users and leaves out those who cannot be assigned, so a page can be short or empty while a later page still holds users.

Input Parameters

Issue ID or key, Project, Query (the start of a display name or email address), Page size and Page token.

Output

Users (array of account ID, display name, email address), Next page token and Is last page.

Create User

Creates a Jira user for an email address and gives the user the products you pick.

Permission required: organization admin with Administer Jira

Licence seats: Each new user takes a paid licence seat of the Atlassian subscription. Guard this step so that a runbook cannot run it by mistake.

With no Products, the user gets no product access. A display name cannot be given. When the user already exists with that access, the job also succeeds. Atlassian blocks some email domains, such as example.com.

Input Parameters

Parameter	Type	Required	Default	Description
Email address	string	Yes	—	The email address of the new user.
Products	array	No	—	Any of jira-core, jira-servicedesk, jira-product-discovery, jira-software. Empty gives no product access.

Output

The user fields, as in Get User Details, plus API URL.

Schema and REST

Get Issue Schema

Lists the fields an issue can have, with the ID, name and type of each field, whether it is required, and the values it allows.

Permission required: Browse Projects (Create Issues for the create screen)

For Create Issue, give a Project and an Issue type, and the action reads the fields of the create screen. For Update Issue, give an Issue ID or key instead, and the action reads the fields the account may edit on that issue. Use the field IDs as keys in Additional fields. A field that is on no screen is not listed; Execute Jira REST API Action with GET /rest/api/3/field lists every field of the site.

Input Parameters

Project (default: Default project) and Issue type, or Issue ID or key — not both.

Output

Fields (array) — each with field ID, name, type, item type (for arrays), required, and allowed values (ID and name).

Execute Jira REST API Action

Sends one request to a Jira Cloud REST API path with the credentials of the connection, for a call that has no action of its own.

Permission required: whatever the called path needs

A JSON response comes back in Body; any other response comes back as base64 text in Content, up to 10 MB. A GET is tried again when Jira is briefly unavailable; POST, PUT and DELETE are not, so a change is never made twice.

Input Parameters

Parameter	Type	Required	Default	Description
HTTP method	string	Yes	GET	GET, POST, PUT or DELETE.
API path	string	Yes	—	Starts with /rest/, for example /rest/api/3/project/search or /rest/agile/1.0/board.
Query parameters	object	No	—	For example {"maxResults": 50, "id": ["10000", "10001"]}. Put them here, not in the path.
Headers	object	No	—	Extra headers. Headers that carry credentials, cookies or a host are ignored.
Request body	any	No	—	JSON sent with POST and PUT only.

Output

Status, Content type, Body (JSON responses), Content (other responses, as base64), and the page outputs Next page token, Is last page, Start at, Page size and Total when the response holds them.

Rate limiting and retries

• When Jira limits the request rate, an action waits as long as Jira asks and then tries again.
• When Jira is briefly unavailable or does not answer within 60 seconds, a read is tried again later, and a write fails with a warning that the change may have been made, so a change is never made twice.
• The triggers do not wait; see their delivery and polling behavior.

Known limitations

• Jira Cloud only. Jira Data Center, Jira Server and Jira Service Management are not supported.
• An issue search page token expires after 7 days.
• Download Attachment refuses a file over 3 MB; Execute Jira REST API Action refuses a response over 10 MB.
• The pick lists of projects, issue types and priorities stop at 500 entries. Type a key, name or ID that is not listed. The polling triggers take an issue type ID only.

Best Practices

• Enter the full site host. Use acme.atlassian.net, not acme.
• Use a classic admin token for real-time triggers. Scoped and service-account tokens run every action and the polling triggers, but Jira refuses them for webhooks.
• Track the API token's expiry. A token lives at most 365 days; when it expires, every job on the connection fails.
• Deprovision before deleting. Deprovision a trigger before deleting its runbook, or its webhook or schedule stays behind.
• Deduplicate on Deduplication ID. Jira can send an event more than once; skip repeats when a workflow creates records or sends mail.
• Expect the polling delay. Polling triggers only deliver issues created or changed more than five minutes ago.
• Use account IDs for users. Turn an email or name into an account ID with Get User Details.
• Use transition names, not IDs. Transition IDs differ between workflows; a name travels between sites.
• Find custom field IDs with Get Issue Schema. They differ per site; use them as keys in Additional fields.
• Guard Create User. Each new user takes a paid licence seat.

Common Use Cases

• Xurrent to Jira escalation: Xurrent event → Create Issue → store the issue key on the Xurrent record.
• Jira to Xurrent sync: New/Updated Issue (real-time) → read Changed fields → update the linked Xurrent record.
• Comment mirroring: New/Updated Comment (real-time) → add a note to the linked Xurrent record; and Xurrent note → Create Comment.
• Status hand-off: Xurrent record solved → Update Issue Status with a transition name and a Comment.
• Carry attachments over: Get Issue Attachments → Download Attachment → Upload Attachment on the Xurrent connector, or on another Jira issue.
• Scheduled sweep: Updated Issue or Search Issues by JQL → Flow connector Loop → process each issue.

References

Jira Cloud REST API reference

• Jira Cloud platform REST API v3
• Issues
• Issue search
• Issue comments
• Issue attachments
• Users

Concepts

• Jira webhooks
• Jira Query Language (JQL)
• Atlassian Document Format

Setup

• Manage API tokens for your Atlassian account
• Service accounts