n8n + Jira Integration: 5 Powerful Workflows You Can Build Today
The n8n Jira integration turns your project board from a place you manually update into one that updates itself. Whether your team runs Scrum sprints or Kanban boards, most of the ticket-shuffling, status-updating, and report-pulling work can be handled by a simple n8n workflow running in the background.
Jira is one of the most widely used project management tools in software teams, but it's also one of the most tedious to keep current. Developers forget to move tickets. PMs spend mornings copying data into spreadsheets. Urgent bugs sit unnoticed in a backlog column. n8n fixes all of that by connecting Jira to the tools your team actually lives in — Slack, GitHub, Google Sheets, email — and keeping everything in sync automatically.
Why Automate Jira with n8n
Jira's built-in automation rules cover basic transitions, but they hit walls fast. You can't easily trigger actions in external tools, the conditions are rigid, and you're locked into Atlassian's ecosystem. n8n changes the equation:
- Cross-tool workflows: Connect Jira to 400+ apps. Move data between Jira and Slack, GitHub, databases, CRMs, or any tool with an API.
- Conditional logic: Use IF nodes, Switch nodes, and expression-based routing to handle complex business rules that Jira's native automation can't express.
- Full API access: n8n's Jira node covers issue CRUD, user management, transitions, comments, and more. Anything the Jira REST API supports, you can automate.
- Self-hosted data control: Your workflow data and credentials stay on your infrastructure — critical for teams handling sensitive project data.
Connecting Jira to n8n
Before building workflows, you need to set up the Jira credential in n8n. The Jira Software node supports both Jira Cloud and Jira Server/Data Center.
For Jira Cloud:
- In your n8n instance, go to Credentials → New Credential → Jira Software.
- Select Cloud as the environment.
- Enter your Jira domain (e.g.,
yourteam.atlassian.net). - Enter the email address associated with your Atlassian account.
- Generate an API token at
id.atlassian.com/manage-profile/security/api-tokensand paste it in. - Click Test to verify the connection.
For Jira Server / Data Center:
- Select Server as the environment.
- Enter your Jira Server base URL.
- Use either a personal access token or username/password authentication.
Tip: Use a dedicated service account for your Jira API token rather than a personal account. This prevents workflows from breaking when someone leaves the team or changes their password.
Once the credential is saved, you can use the Jira Software node (for actions like creating issues) and the Jira Trigger node (for reacting to events via webhooks) in any workflow.
Workflow 1: Slack Messages to Jira Issues
Bug reports and feature requests often surface in Slack channels, then get lost in the scroll. This workflow catches them and creates Jira issues automatically.
How it works:
- Slack Trigger node — listens for messages in a specific channel (e.g.,
#bug-reports) or messages with a specific emoji reaction (like 🐛). - IF node — filters out bot messages and threads to avoid duplicates.
- Jira Software node — action: Create Issue. Map the Slack message text to the issue description, the sender's name to the reporter field, and set the project key and issue type (Bug, Task, Story).
- Slack node — posts a reply in the thread with the new Jira issue link, so the team knows it's been tracked.
Key configuration: In the Jira node, use an expression like {{$json.text.substring(0, 80)}} for the issue summary to keep titles concise, and put the full message in the description field. Set labels like slack-reported to distinguish these from manually created tickets.
Workflow 2: GitHub PR to Jira Status Sync
Developers open pull requests in GitHub but forget to update the Jira ticket. This workflow keeps Jira status in sync with your Git activity — no manual dragging of cards required.
How it works:
- GitHub Trigger node — listens for
pull_requestevents (opened, merged, closed). - Set node — extracts the Jira issue key from the branch name or PR title using a regex expression like
{{$json.pull_request.head.ref.match(/[A-Z]+-\d+/)?.[0]}}. Most teams already include the ticket key in branch names (e.g.,PROJ-142-fix-login-bug). - Switch node — routes based on the PR action:
opened→ transition to "In Review",merged→ transition to "Done",closed(without merge) → transition back to "To Do". - Jira Software node — action: Transition Issue. Uses the extracted issue key and the target transition ID for each status.
/rest/api/2/issue/{issueKey}/transitions to find the correct IDs for your workflow statuses. You can call this directly from n8n using an HTTP Request node during setup.Workflow 3: Automated Sprint Reports in Google Sheets
Every sprint review starts with someone pulling numbers out of Jira manually. This n8n workflow generates a sprint summary in Google Sheets automatically — ready for standup or stakeholder updates.
How it works:
- Schedule Trigger node — runs every Friday at 4 PM (or whenever your sprint ends).
- HTTP Request node — calls the Jira REST API endpoint
/rest/agile/1.0/board/{boardId}/sprint/{sprintId}/issueto fetch all issues in the current sprint. Use the Jira credential for authentication. - Code node — aggregates the data: count of completed vs. incomplete issues, total story points delivered, issues by assignee, and any items that were added mid-sprint.
- Google Sheets node — appends a new row (or creates a new sheet tab) with the sprint metrics.
- Slack node (optional) — posts a formatted summary to your team channel with key metrics and a link to the spreadsheet.
Over time, this builds a historical record of sprint velocity that's far more useful than Jira's built-in velocity chart — because you control exactly what gets measured and how it's displayed.
Workflow 4: SLA Breach Escalation for Jira Issues
Support teams and DevOps squads often have SLA commitments — critical bugs must be acknowledged within 1 hour, resolved within 4 hours. This workflow monitors Jira for issues at risk of breaching SLA and escalates them before it's too late.
How it works:
- Schedule Trigger node — runs every 15 minutes.
- Jira Software node — action: Get All Issues using a JQL query:
project = "SUPPORT" AND priority in (Highest, High) AND status != Done AND created >= -4h. - Code node — calculates how long each issue has been open and checks it against your SLA thresholds (e.g., 1 hour for P1, 4 hours for P2).
- IF node — splits issues into "approaching breach" and "already breached."
- Slack node / Email node — sends targeted alerts. Approaching-breach issues get a warning in the team channel. Already-breached issues trigger a direct message to the team lead and an email to the engineering manager.
- Jira Software node — adds a comment to the breached issue: "⚠️ SLA breach — escalated to [manager name]" so there's an audit trail.
This workflow alone can save a support team from missed SLA penalties and the awkward post-mortem conversations that follow.
Workflow 5: New Hire Onboarding Task Creation
When a new engineer joins the team, someone has to create a dozen Jira tickets: set up dev environment, complete security training, review architecture docs, attend intro meetings. This workflow creates the full set of onboarding tickets from a single trigger.
How it works:
- Webhook node — receives a POST request with the new hire's name, email, team, and start date. You can trigger this from an HR tool, a Google Form, or even a Slack slash command.
- Code node — generates an array of onboarding tasks from a template. Each task has a title, description, assignee, due date (relative to start date), and labels.
- SplitInBatches node — iterates over the task array.
- Jira Software node — action: Create Issue for each task. Sets the project, issue type (Task), summary, description, assignee (the new hire or their buddy), and a due date calculated from the start date.
- Slack node — notifies the team channel that onboarding tickets have been created, with a Jira filter link to view them all.
Store your onboarding task template in the Code node as a JSON array. When the process changes, update the template in one place and every future new hire gets the updated checklist.
Tips for Running Jira Workflows in Production
Once your workflows are built and tested, a few practices will keep them running reliably:
- Use error handling: Add an Error Trigger workflow that catches failures from your Jira workflows and sends a Slack or email notification. Jira API rate limits and token expirations are the most common failure modes.
- Watch your API limits: Jira Cloud allows roughly 100 requests per minute for standard plans. If you're polling frequently or creating many issues in batches, add a Wait node between iterations to stay under the limit.
- Test with a sandbox project: Create a test Jira project (e.g.,
TEST) and run your workflows against it before pointing them at production boards. - Pin your workflow versions: When a workflow is stable, activate it and avoid editing the production version. Duplicate it first if you want to experiment.
- Keep credentials secure: Running n8n on a managed platform like n8nautomation.cloud means your Jira API tokens are stored encrypted and your instance is backed up automatically — no risk of losing credentials to a server crash.
Tip: If your team uses Jira Service Management (JSM), the same Jira Software node works with JSM projects. You can automate customer-facing ticket routing, approvals, and escalations with the same patterns described above.
Jira is most useful when it reflects reality — and reality moves fast. Instead of relying on people to update tickets at every step, let n8n handle the mechanical parts while your team focuses on the work itself. With a managed n8n instance on n8nautomation.cloud, these workflows run 24/7 without you worrying about server uptime, backups, or updates. Set them up once, and your Jira board stays accurate on its own.