What happens if the branch name has multiple Jira keys?

The regex captures only the first match. If you need to update multiple tickets, duplicate the Jira action step and modify the pattern to capture additional keys using different group indices.

Can this work with draft pull requests?

No, GitHub's 'New Pull Request' trigger only fires on published PRs. Draft PRs require a separate 'Pull Request Ready for Review' trigger if you want status updates on draft publishing.

How do I handle different Jira projects with different status names?

Add a Formatter step after pattern extraction to map project prefixes to status names. Use a lookup table that converts PROJ keys to 'In Review' and TEAM keys to 'Under Review'.

Will this trigger if someone pushes new commits to an existing PR?

No, this only triggers on PR creation. New commits to existing PRs don't fire the 'New Pull Request' event, so status stays unchanged when developers push updates.

Beginner~8 min setupDeveloper Tools & Project ManagementVerified April 2026

How to Update Jira Status from GitHub Pull Requests with Zapier

Automatically move Jira tickets to In Review when a pull request references the ticket key in the branch name.

Steps and UI details are based on platform versions at time of writing — check each platform for the latest interface.

Zapier

Also on:Make N8n Power-automate Pipedream

Best for

Development teams with consistent Jira key branch naming who want automated status updates without custom development.

Not ideal for

Teams with inconsistent branch naming conventions or complex Jira workflows requiring conditional status transitions.

Sync type

polling

Use case type

sync

Real-World Example

💡

A 12-person development team at a B2B SaaS company uses this to automatically move Jira tickets to 'In Review' when developers open pull requests. Before automation, developers forgot to update ticket status 40% of the time, leaving project managers guessing which features were actually under review. Now status updates happen instantly without developer action.

What Will This Cost?

Drag the slider to your expected monthly volume.

Monthly workflow runs

/mo

505005K50K

Each platform counts differently — Zapier: 1 task per trigger. Make: 1 operation per module per record. n8n: 1 execution per run.

$30/mo if billed monthly

Pipedream

$29/mo

Basic plan

Prices shown for annual billing. Based on published pricing as of April 2026.

Estimated ROI

1000

min saved/mo

$583

labor value/mo

Free

no platform cost

Based on ~2 min manual effort per operation at $35/hr fully loaded labor cost.

Implementation

Before You Start

Make sure you have everything ready.

Admin access to the GitHub repository for webhook creation

Jira admin permissions to modify issue statuses and create API connections

An existing 'In Review' status in your Jira workflow (or equivalent transition status)

Team already includes Jira ticket keys in branch names like PROJ-123

Field Mapping

Map these fields between your apps.

Field	API Name	Description
Required
Issue Key	`issue_key`	The Jira ticket identifier extracted from branch name (e.g., PROJ-123)
Transition Status	`transition`	Target status name in your Jira workflow, typically 'In Review' or 'Code Review'
Branch Name	`head.ref`	GitHub branch name containing the Jira key, used for pattern extraction

2 optional fields▸ show

Pull Request URL	`html_url`	GitHub PR link that can be added to Jira comments for reference
Author	`user.login`	GitHub username of PR creator, useful for Jira assignee updates

Step-by-Step Setup

Zap Editor > Trigger > Choose App

Connect GitHub account

Add your GitHub account to Zapier. You'll need admin access to the repository where pull requests are created.

1Click 'Make a Zap' from your Zapier dashboard
2Search for 'GitHub' in the app selector
3Select 'Pull Request' as the trigger event
4Click 'Sign in to GitHub' and authorize Zapier

✓ What you should see: GitHub shows as connected with a green checkmark next to your username.

Zapier settings

Connection

Choose a connection…Add

click Add

GitHub

Authorize Zapier

popup window

✓

Connected

green checkmark

Zap Editor > Trigger > Set up trigger

Set pull request trigger

Configure the trigger to fire when new pull requests are opened. This catches PRs across all branches in your selected repository.

1Select 'New Pull Request' from the trigger event dropdown
2Choose your repository from the Repository dropdown
3Set Action to 'opened' to trigger only on new PRs
4Click 'Continue' to proceed to testing

✓ What you should see: The trigger configuration shows your repository name and 'opened' action selected.

⚠

Common mistake — Don't select 'Any Action' — that triggers on comments, merges, and closes too, creating noise.

Zapier

click +

search apps

GitHub

Set pull request trigger

GitHub

module added

Zap Editor > Trigger > Test

Test GitHub trigger

Pull in a recent PR to use as sample data. Zapier needs real data to map fields in later steps.

1Click 'Test trigger' to fetch recent pull requests
2Select a PR that has a branch name with a Jira key (like PROJ-123)
3Click 'Continue with selected record'

✓ What you should see: Sample data appears showing branch name, PR title, and other GitHub fields.

⚠

Common mistake — If no PRs appear, create a test PR in your repo first — Zapier can't map fields without sample data.

Zapier

▶ Turn on & test

executed

✓

GitHub

✓

Jira

🔔 notification

received

Zap Editor > Action > Choose App

Add Jira connection

Connect your Jira instance as the action app. You'll need Jira admin permissions to modify issue statuses.

1Click the '+' button to add an action step
2Search for and select 'Jira Software'
3Choose 'Update Issue' as the action event
4Click 'Sign in to Jira' and enter your Jira URL and credentials

✓ What you should see: Jira Software appears as connected with your instance URL displayed.

Zap Editor > Action > Add Between Steps

Add text parser filter

Insert a Text by Zapier step to extract the Jira ticket key from the branch name. This step sits between GitHub and Jira.

1Click '+' to add another action before the Jira step
2Select 'Formatter by Zapier' from the apps list
3Choose 'Text' as the formatter type
4Select 'Extract Pattern' as the transform

✓ What you should see: Formatter by Zapier appears as step 2, with Jira pushed to step 3.

⚠

Common mistake — Don't use 'Replace' transform — it won't isolate the ticket key from the full branch name.

GitHub

trigger

filter

Condition

matches criteria?

yes — passes through

no — skipped

Jira

notified

Zap Editor > Formatter > Extract Pattern Setup

Configure pattern extraction

Set up regex to pull Jira ticket keys from branch names. This handles formats like feature/PROJ-123-add-login or bugfix/TEAM-456.

1In the Input field, select 'Head Ref Name' from GitHub data
2Set Pattern to: ([A-Z]+-\d+)
3Leave other fields blank
4Click 'Continue' to test the extraction

✓ What you should see: The test shows the extracted ticket key (like PROJ-123) in the output field.

⚠

Common mistake — Test with your actual branch naming — some teams use lowercase or different separators.

Zap Editor > Jira > Update Issue Setup

Configure Jira issue update

Set up the Jira action to update the ticket status. Map the extracted ticket key to the issue identifier field.

1In the Issue field, select the extracted pattern from step 6
2Set Status to 'In Review' (or your equivalent status name)
3Leave Comment field blank unless you want to add a note
4Click 'Continue' to proceed to testing

✓ What you should see: The Jira configuration shows your ticket key mapped and 'In Review' selected as status.

⚠

Common mistake — Status names must match exactly — 'In Review' vs 'In review' will cause failures.

Zap Editor > Jira > Test

Test the complete workflow

Run the full Zap with your sample data to verify the Jira ticket actually updates. This catches permission and field mapping issues.

1Click 'Test action' in the Jira step
2Check your Jira project to confirm the ticket moved to In Review
3Verify the transition happened without errors
4Click 'Turn on Zap' if the test succeeded

✓ What you should see: Zapier shows 'Success!' and your Jira ticket appears in the In Review column.

⚠

Common mistake — If the test fails with 'Issue not found', double-check the ticket key extraction in step 6.

Drop this into a Zapier Code step.

Copy this templateFor complex branch naming, use this regex pattern instead: (?:feature|bugfix|hotfix)\/(\w+-\d+) — it captures ticket keys only from standard Git Flow prefixes and ignores experimental or personal branches.

▸ Show code

For complex branch naming, use this regex pattern instead: (?:feature|bugfix|hotfix)\/(\w+-\d+) — it captures ticket keys only from standard Git Flow prefixes and ignores experimental or personal branches.

... expand to see full code

For complex branch naming, use this regex pattern instead: (?:feature|bugfix|hotfix)\/(\w+-\d+) — it captures ticket keys only from standard Git Flow prefixes and ignores experimental or personal branches.

Scaling Beyond 300+ PRs per month+ Records

If your volume exceeds 300+ PRs per month records, apply these adjustments.

Upgrade to Professional plan

Zapier's Starter plan polls every 15 minutes, causing delays. Professional polls every 2 minutes and includes webhook support for faster triggering.

Add error retry logic

High-volume repos hit Jira rate limits more often. Set error handling to 'Hold' with 3 retries instead of 'Skip' to avoid missing status updates during API slowdowns.

Going live

Production Checklist

Before you turn this on for real, confirm each item.

Test pattern extraction with 5+ different branch names from your actual repo

Applies when: Always

Verify Jira status transition works from all possible starting states (To Do, In Progress, etc.)

Applies when: Always

Set up Zap error notifications to Slack or email for failed transitions

Applies when: Always

Enable 'Hold' error handling instead of 'Skip' to retry failed Jira API calls

Applies when: Always

Configure webhook retry settings in GitHub if your team opens 50+ PRs daily

Applies when: High volume

Troubleshooting

Common errors and how to fix them.

Frequently Asked Questions

Common questions about this workflow.

Analysis

VerdictWhy Zapier for this workflow

Use Zapier for this if your team already follows consistent branch naming with Jira keys and you want zero maintenance overhead. Setup takes 15 minutes and it just works — no server management or custom webhook handling. The main alternative is a GitHub Action, which gives you more control but requires writing and maintaining YAML configs plus managing secrets.

Cost

This workflow burns 1 task per pull request. A team opening 200 PRs monthly hits 200 tasks, fitting Zapier's Starter plan at $20/month. Make would handle the same volume for $9/month, and N8N is free self-hosted. But for most teams, the $11 monthly difference isn't worth the deployment complexity.

Tradeoffs

Make handles GitHub webhooks faster with true real-time processing, while Zapier polls every 1-5 minutes depending on your plan. N8N gives you full regex debugging tools and custom JavaScript transforms if your branch naming gets complex. But Zapier's guided setup and built-in error handling beats both for teams that want to set it once and forget it.

You'll discover GitHub's webhook reliability varies by repository activity — high-traffic repos sometimes miss webhook deliveries during GitHub incidents. Zapier's polling backup catches missed events, but with a delay. Also, Jira's transition permissions are project-specific, so the same Zap might work for one project but fail for another if workflows differ.

Ideas for what to build next

→
Add PR merge to Done status — Create a second Zap that moves Jira tickets to 'Done' when pull requests are merged, completing the development lifecycle tracking.
→
Post PR links in Jira comments — Enhance the current Zap to add a comment with the GitHub PR URL and author name, giving project managers direct links to code changes.
→
Notify team in Slack — Add a Slack action that posts to your dev channel when tickets move to In Review, keeping the team aware of what's ready for testing.