Jira Software n8n integrationAutomate Jira Software with n8n.

Every edit made to a ticket leaves a line in its changelog, and this operation reads that history back into the workflow: which field moved, and when.

• Issue Key: the reference as it reads in Jira, like OPS-12, often {{ $json.key }} when a trigger supplies it.
• Return All: switched on, n8n walks every page of the history; switched off, Limit caps how many entries come back.

Files a new ticket and returns it with the key Jira just assigned, which the nodes downstream reuse to comment, attach or update.

• Project: picked from the list or given by ID, it decides where the issue lands.
• Issue Type: chosen the same way, from the types the project offers.
• Summary: the single line that becomes the ticket title.
• Additional Fields: where Description, Assignee, Priority, Parent Issue Key and Custom Fields live when a title is not enough.

Removes a ticket from Jira for good. The node makes the subtask question explicit instead of deciding for you.

• Issue Key: the ticket that goes.
• Delete Subtasks: required here, so the workflow states what happens to the children rather than leaving it to a default.

Pulls one ticket back as JSON when the workflow only has its key to work from, which is the usual situation right after a webhook.

• Issue Key: the key of the ticket to read.
• Simplify: returns a trimmed response instead of the raw payload, which keeps later expressions readable.
• Fields: in Additional Fields, a comma separated list to narrow the response; *all returns everything, and a field prefixed with a minus is excluded.

Search, essentially. No key is required: the operation runs a query and returns every issue that matches it.

• JQL: in Options, the Jira query language expression that defines the set, the same syntax as the search box in Jira.
• Return All: on for a full export, off to stop at Limit.
• Expand: adds blocks to each issue, such as changelog or transitions, when the list alone is too thin.

Jira sends the email itself here: the operation drops a notification about a ticket into Jira's mail queue, addressed to the people you name.

• Issue Key: the ticket the email is about.
• Notification Recipients: who receives it, through Reporter, Assignee, Watchers, Voters, User Names or IDs and Group Names or IDs, or as raw JSON when JSON Parameters is on.
• Subject: in Additional Fields, next to Text Body and HTML Body; left empty, Jira uses the issue key and summary.

Before moving a ticket, a workflow has to know where it is allowed to go. This returns the transitions available on the issue, given the status it sits in.

• Issue Key: the ticket to inspect.
• Transition ID: in Additional Fields, to ask about one transition instead of the full list.
• Expand: accepts transitions.fields, which describes the fields on each transition screen, hidden ones excluded.

Edits a ticket field by field and leaves everything else untouched, which makes it safe to run on issues people are working in.

• Issue Key: the ticket to edit.
• Update Fields: the collection holding Summary, Description, Assignee, Priority, Labels, Issue Type, Parent Issue Key and Custom Fields.
• Status: also in Update Fields, and this is how a workflow moves a ticket along, since the node has no separate transition operation.

Files travel through n8n as binary data, and this operation pushes one of them onto a ticket.

• Issue Key: the ticket that receives the file.
• Input Binary Field: the name of the binary field on the incoming item that holds the file, as the node before it named the field.

Retrieves a single attachment by its own identifier, so the ticket it hangs on never enters the call.

• Attachment ID: the ID of the attachment, usually carried over from an earlier step.
• Download: required, and it goes hand in hand with the output field below.
• Put Output File in Field: the name of the output binary field the file is placed in.

Works from the ticket instead of the file: everything attached to the issue comes back in one call.

• Issue Key: the ticket whose attachments are listed.
• Download and Put Output File in Field: both required, the second naming the output binary field the files land in.
• Return All: on to take the whole set, off to stop at Limit.

Deletes one file and asks for nothing else: the identifier of the attachment is the whole call, and the ticket it belonged to stays where it is.

• Attachment ID: the ID of the attachment to remove.

Comments are where an automation talks back to the people on the ticket. This posts one under the issue.

• Issue Key: the ticket the comment belongs to.
• Comment: the text itself.
• Document Format (JSON): with JSON Parameters on, the body goes in as Atlassian Document Format instead of plain text.
• Use Wiki Markup: in Options, parses wiki formatting in the comment; it is false unless you set it.

Reads one comment back, which takes both identifiers: the ticket, then the comment inside it.

• Issue Key: the ID or key of the issue holding the comment.
• Comment ID: the ID of the comment to read.
• Expand: in Options, accepts Rendered Body, which returns the comment rendered in HTML rather than as stored.

Returns the whole discussion on a ticket in one array, which is what a summary step needs to work from.

• Issue Key: the ID or key of the issue whose thread is read.
• Order By: Created Ascending or Created Descending, so the newest reply is either first or last.
• Return All: on for a long thread, off to stop at Limit.

Takes a comment off a ticket permanently. Unlike the attachment version, it needs both identifiers to find what to remove.

• Issue Key: the ID or key of the issue.
• Comment ID: the ID of the comment to remove.

Rewrites a comment in place, which keeps a thread readable when a status line is refreshed several times a day instead of stacked.

• Comment ID: the comment to rewrite, alongside the Issue Key it sits under.
• Comment: the replacement text.
• Document Format (JSON): the Atlassian Document Format alternative, used when JSON Parameters is on.

Onboarding can finish inside Jira: the node creates the account rather than leaving it on an admin checklist.

• Username, Email Address and Display Name: the three required fields.
• Password: in Additional Fields; left empty, a random password is generated.
• Notification: sends the person the email confirming they were added to Jira.

The mirror image of onboarding, with one surprise: no field is required, and the account is identified by an optional one.

• Account ID: the account ID of the user to delete, the only field the operation reads.

Turns an account ID into a person: the display name, the email and, on request, the groups behind it.

• Account ID: the account ID of the user to retrieve.
• Expand: in Additional Fields, groups adds every group the user belongs to, applicationRoles adds the applications they can access.