Jira Action

Creates, finds and moves Jira issues from a flow. Twelve operations over Atlassian Cloud, including JQL search and issue transitions — the two that turn a webhook into “file it, assign it, move it to In Progress”. And the other way round: a Jira trigger fires a flow when an issue or a comment changes.

Setup

An Atlassian connection. The scopes it was granted decide what the node can do: reading issues and writing them are separate permissions, so a read-only connection fails on create with a 403. Whatever the node writes, it writes as the person who connected the account: Jira shows them as the author — which matters if the same project also fires a flow.

The credential shows which Atlassian account it is connected with — its email, and the Jira site underneath. Check it when a call fails with a 403: with two Atlassian accounts it is easy to connect the one with fewer permissions.

Mode — action or AI toolkit

Once the connection is picked, the node asks for a Mode. In Single operation you pick one operation and fill its fields, and the node does that every time it runs. AI toolkit turns the twelve operations into tools that an AI Node — or an MCP client, through one of your MCP servers — calls by name, choosing which one and with what arguments.

The model can name things instead of passing their IDs: issue_type takes the type's name (Task, Bug…), transition the transition or its target status (“Done”), assignee an email or a display name, and link_type the link's name. The node looks them up in Jira; when one doesn't match — or matches several people — the error lists the options, so the model can correct itself. When the node has a project, project_key becomes optional and defaults to it. A comment given to transition_issue ends up on the issue, as in Move issue.

What you control

• Where the model can work. This node's project (the default) keeps the model in one project — the one you pick in the toolkit settings or, when empty, the Single operation's. An issue of another project is refused before Jira is called (the project comes from the key, so a numeric issue id is refused too), and every JQL search is limited to that project. custom_fields cannot take an issue out of it either: a project there is not applied. Any project opens every project the credential reaches.
• Characters per call sent to the model. 20,000 by default, anything from 1,000 to 200,000.
• Deleting starts blocked. Jira has no trash through the API. Unblock delete_issue under Block these tool calls if the agent needs it; block others the same way — transition_issue and assign_issue to keep the agent from moving work.

Attachments come from the event or a URL

A model cannot hand the node a file, so add_issue_attachment takes a reference in file_url:

• A file that came with the event — an email attachment, a webhook upload — by its id, the one the agent sees under “Files in this event”.
• A public URL. The node downloads it — never from a private or internal address, also after a redirect.

Either way, up to 8 MB. The name defaults to the file's own name, or to the last part of the URL.

What goes back to the model

The same response as the operation, made readable: descriptions and comments come as text instead of Atlassian Document Format, without avatar and API links. Searches and comments return 20 unless the model asks for more; items that don't fit the characters limit are left out whole, with a notes field saying how many. Arguments are used as written: a {{payload.x}} the model writes is not resolved against the flow.

Testing a tool

{ "operation": "search_issues", "jql": "status != Done ORDER BY updated DESC", "max_results": 5 }

Operations

The Operation dropdown decides what the node does and which fields appear under it. These are the exact values the API validates against:

What the fields send

Every field takes templates — {{payload.issueKey}} from a Jira trigger, {{$("Webhook").payload.title}} from an earlier node — and the result goes to Jira as plain text, exactly as typed: nothing is escaped. A summary like [Bug] she said "hello" arrives with its brackets and its quotes, and a description keeps its line breaks.

Description and comments follow Format. In plain text, the default, the node turns them into Atlassian Document Format for you — one paragraph per block, and a line break wherever you type one. In raw ADF, the value is the ADF document itself. Other fields (JSON) takes an object in Jira's own shape — { "labels": ["urgent"], "customfield_10042": 3 } — merged into the issue's fields, with the templates inside it filled in. Through the API, a description, a comment or customFields can also be saved as an object instead of a string — an ADF document, a fields object — and it is sent as that object.

Names or ids

The pickers store ids, but you can also type names, as the toolkit does. The node looks them up in Jira when it runs:

• Transition (Move issue) — the transition's name or the status it leads to (“Done”), or its id.
• Issue type (Create issue) — the type's name (“Bug”), or its id.
• Assignee (Assign issue, Create issue) — an email or a display name, or the accountId. The people picker searches Jira as you type, instead of listing only the first fifty.

Names are what make a templated issue work. With {{payload.issueKey}} the issue is only known when the flow runs, so the picker cannot list its transitions: type the transition's name. When a name matches nothing — or several people — the run fails with an error that lists the valid options.

Move issue with a comment

Comment (optional) is added to the issue once the transition is done. Jira drops a comment sent along with a transition that has no screen for it; when that happens, the node adds it right after, as a regular comment, so it always shows up. If the transition fails, no comment is added. The toolkit's transition_issue works the same way.

Attach file

File from payload points at a file the flow carries — not a URL. Any of these works:

• {{payload._file}} — what an HTTP node, a Drive download or a File Transform left.
• {{payload._files[0]._file}} — the first file a webhook received.
• {{payload.attachments[0]._file}} — the first attachment of an email, from a Gmail trigger with Download attachments on.
• The file's id, typed or from a template.

Up to 8 MB per file, the same as the toolkit. File name empty keeps the name the file carries.

When Jira says no

A failed call keeps Jira's status — 400, 403, 404 — and Jira's own explanation, so the run says what Jira said: a key that doesn't exist fails with a 404 and Issue does not exist or you do not have permission to see it. HostWebhook's own messages — a missing issue key, a name that matches nothing — are in English and say what to change.

Jira's rate limit (429) and its outages (503) are retried. A 403 is not: it usually means the connection lacks a permission or the person who connected it cannot see the project, and retrying would not change that.

Delete issue needs more than writing. In a team-managed space only the Administrator role can delete — someone who gets in through the space's open access can create and edit but not delete. In a company-managed project it is the Delete work items permission of its permission scheme. A 403 on Delete issue says so before Jira's own message.

Gotchas

• A transition is not a field. You cannot set status directly — you apply a transition, and only the transitions the workflow allows from the current status are valid.
• Transition ids are per workflow. The id for “Done” in one project is not the id in another. When the issue comes from the payload, type the transition's name (“Done”) rather than an id — see Names or ids.
• Custom fields are customfield_NNNNN, not their display name. Their ids differ between sites.
• JQL search is paginated and its output is iterable, so a Loop can walk the results.
• Personal data pulled from Atlassian carries reporting obligations — see your Atlassian agreement before storing user records outside Jira.