What happens if a branch name has multiple ticket keys?

The regex captures only the first match. Modify the pattern to global matching or use Make's split function to handle multiple tickets per branch.

Can this work with GitHub Enterprise or self-hosted instances?

Yes, but you'll need to configure Make's GitHub connection with your custom domain and ensure webhook traffic can reach Make's servers through firewalls.

How do I handle different Jira projects with different workflow transition IDs?

Add a router after text parser to check the project prefix (PROJ vs DEV) and route to different Jira modules with project-specific transition IDs.

Will this trigger on draft pull requests?

No, the 'opened' event only fires for ready-for-review PRs. Draft PRs use 'ready_for_review' event which you'd need to add separately.

What if someone renames a branch after the PR is opened?

This won't retrigger since GitHub doesn't send webhook events for branch renames. You'd need a separate scenario watching for PR edit events.

Beginner~12 min setupDeveloper Tools & Project ManagementVerified April 2026

How to Move Jira Tickets to In Review from GitHub PRs with Make

Automatically updates Jira ticket status to In Review when a GitHub 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.

Make

Also on:Zapier N8n Power-automate Pipedream

Best for

Development teams with consistent branch naming who need real-time Jira status updates

Not ideal for

Teams with inconsistent branch naming or complex ticket key formats across multiple projects

Sync type

real-time

Use case type

sync

Real-World Example

💡

A 12-person startup dev team uses this to automatically move tickets to In Review when PRs are opened for code review. Before automation, developers manually updated 15-20 tickets daily in Jira after creating PRs, often forgetting until standups. Now ticket status stays accurate and project managers see review progress in real-time without nagging developers.

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

Skip the setup

Import this workflow directly into Make

Copy the pre-built Make blueprint and paste it straight into Make. All modules, filters, and field mappings are already configured — you just need to connect your accounts.

Before You Start

Make sure you have everything ready.

GitHub repository admin access to configure webhooks

Jira project admin access to get transition IDs

Jira API token generated from Atlassian account settings

Team follows branch naming convention with ticket keys

Make account with available operations quota

Field Mapping

Map these fields between your apps.

Field	API Name	Description
Required
Pull Request Branch	`head.ref`	Branch name containing Jira ticket key like feature/PROJ-123
Ticket Key Match	`$1`	Regex capture group extracting ticket key from branch name
Transition ID	`transition.id`	Numeric ID for moving ticket to In Review status in Jira workflow

3 optional fields▸ show

PR Title	`title`	Pull request title for logging or notifications
Author Username	`user.login`	GitHub username who opened the PR for audit tracking
Repository Name	`repository.name`	Repo name for scenarios monitoring multiple repositories

Step-by-Step Setup

Scenarios > Create new scenario > +

Create New Make Scenario

Start a blank scenario in Make to connect GitHub pull request events to Jira status updates. This will be the container for your entire automation workflow.

1Log into Make and click 'Create a new scenario'
2Click the + button to add your first module
3Search for 'GitHub' in the app list
4Select 'GitHub' from the results

✓ What you should see: You should see a GitHub module added to your scenario canvas with configuration options on the right panel.

GitHub > Watch Pull Requests > Connection

Configure GitHub Pull Request Trigger

Set up the webhook trigger to fire when pull requests are opened. This monitors your repository for new PRs and captures the branch name containing ticket keys.

1Select 'Watch Pull Requests' from the GitHub triggers list
2Connect your GitHub account or select existing connection
3Choose your target repository from the dropdown
4Set Event to 'opened' only
5Click OK to save the trigger configuration

✓ What you should see: The GitHub module shows your connected account and repository name with a green connection indicator.

⚠

Common mistake — Don't select 'synchronize' event - that fires on every commit push and will spam your workflow

Make

click +

search apps

GitHub

Configure GitHub Pull Reques…

GitHub

module added

Text parser > Match pattern

Add Text Parser Module

Insert a text parser to extract Jira ticket keys from branch names. This uses regex to find patterns like PROJ-123 in the branch reference.

1Click the + button after the GitHub module
2Search for 'Text parser' and select it
3Choose 'Match pattern' as the function
4In Pattern field, enter: ([A-Z]+-[0-9]+)
5Map the Text field to GitHub > Pull Request > Head > Ref

✓ What you should see: The text parser module shows your regex pattern and the GitHub branch reference mapped as input text.

⚠

Common mistake — Use head.ref not base.ref - base.ref is the target branch (usually main), not the feature branch with your ticket key

Flow control > Router

Add Router for Conditional Logic

Add a router to handle cases where branch names don't contain Jira keys. This prevents the scenario from failing when PRs don't follow the naming convention.

1Click + after the text parser module
2Select 'Flow control' then 'Router'
3The router appears with two empty paths
4Click on the first path to configure it

✓ What you should see: You see a router with two branching paths, with the first path highlighted for configuration.

⚠

Common mistake — Filters are the most common place setups break. Double-check the field name and value exactly match what your app sends — a single capital letter difference will block everything.

GitHub

trigger

filter

Condition

matches criteria?

yes — passes through

no — skipped

Jira

notified

Router > Filter > Condition

Configure Router Filter

Set up the filter condition to only proceed when a Jira key is found. This route processes PRs with valid ticket references while ignoring others.

1Click the wrench icon on the first router path
2Set Label to 'Jira Key Found'
3Set Condition to 'Text parser: $1 exists'
4Set the condition operator to 'Is not equal to' empty
5Click OK to save the filter

✓ What you should see: The router path shows 'Jira Key Found' as the label with a filter icon indicating the condition is set.

⚠

Common mistake — Use 'exists' not 'is not empty' - the text parser returns null when no match is found, not an empty string

Jira Software > Make an API Call > Connection

Add Jira Connection Module

Connect to your Jira instance to enable ticket status updates. This establishes the authentication needed to modify issue statuses programmatically.

1Click + on the filtered router path
2Search for 'Jira Software' and select it
3Choose 'Make an API Call' from the actions
4Select 'POST' as the HTTP method
5Connect your Jira account with API token

✓ What you should see: Jira module shows connected status with your instance URL and a green connection badge.

⚠

Common mistake — Use 'Make an API Call' not 'Update Issue' - the Update Issue action doesn't handle status transitions properly

Jira > API Call > URL Configuration

Configure Jira API Endpoint

Set the API endpoint to transition the ticket status. This calls Jira's transitions endpoint to move tickets through your workflow states.

1Set URL to: /rest/api/3/issue/{{text parser.$1}}/transitions
2Set Method to 'POST'
3In Headers, add 'Content-Type: application/json'
4In Body, enter: {"transition":{"id":"YOUR_TRANSITION_ID"}}
5Replace YOUR_TRANSITION_ID with your workflow's In Review transition ID

✓ What you should see: The API call shows the dynamic URL with the ticket key from text parser and your transition ID in the request body.

⚠

Common mistake — Get the transition ID from Jira admin, not the status name - transition IDs are numeric and workflow-specific

Scenario > Run once > Execution log

Test with Sample Data

Run a test to verify the integration works with real GitHub and Jira data. This validates your regex pattern captures ticket keys and Jira accepts the status change.

1Click 'Run once' at the bottom of the scenario
2Create a test PR with branch name like 'feature/PROJ-123-new-feature'
3Wait 10-15 seconds for the webhook to trigger
4Check the execution log for successful completion
5Verify the Jira ticket moved to In Review status

✓ What you should see: Execution log shows green checkmarks for all modules and the Jira ticket appears in In Review column.

⚠

Common mistake — Test with a real ticket in the correct starting status - you can't transition tickets that are already In Review or Done

Make

▶ Run once

executed

✓

GitHub

✓

Jira

🔔 notification

received

Module > Add error handler > Ignore

Handle Error Cases

Add error handling for failed Jira API calls and invalid ticket keys. This prevents the scenario from breaking when tickets don't exist or transitions fail.

1Right-click the Jira module and select 'Add error handler'
2Choose 'Ignore' as the error handling directive
3Add a second router path for when no Jira key is found
4Label the second path 'Skip - No Ticket Key'
5Leave the second path empty (it will complete successfully)

✓ What you should see: Your scenario shows error handling on the Jira module and both router paths properly configured.

⚠

Common mistake — Don't use 'Break' error handling in production - it will stop processing other PRs if one ticket key is invalid

Scenario > Toggle ON > Confirm

Activate the Scenario

Turn on the scenario to start monitoring GitHub PRs automatically. This enables the webhook listener and begins processing new pull requests in real-time.

1Click the toggle switch in the bottom left to 'ON'
2Confirm the activation in the popup dialog
3Verify the webhook appears in your GitHub repo settings
4The scenario status shows 'Active' with a green indicator

✓ What you should see: Scenario shows 'Active' status and GitHub webhooks page lists the Make webhook URL under recent deliveries.

⚠

Common mistake — Check GitHub webhook deliveries after activation - a 404 response means the webhook URL wasn't registered properly

Drop this into a Make custom function.

Copy this template{{replace(replace(1.head.ref; "feature/"; ""); "bugfix/"; "")}} - Use this in text parser to strip common branch prefixes before regex matching ticket keys

▸ Show code

{{replace(replace(1.head.ref; "feature/"; ""); "bugfix/"; "")}} - Use this in text parser to strip common branch prefixes before regex matching ticket keys

... expand to see full code

{{replace(replace(1.head.ref; "feature/"; ""); "bugfix/"; "")}} - Use this in text parser to strip common branch prefixes before regex matching ticket keys

Scaling Beyond 100+ PRs per day+ Records

If your volume exceeds 100+ PRs per day records, apply these adjustments.

Add Operation Batching

Group multiple ticket updates using Make's array aggregator if PRs reference multiple tickets. This reduces API calls from 3 per ticket to 1 per batch.

Cache Transition IDs

Store Jira transition IDs in Make's data store instead of hardcoding them. This prevents API calls to fetch transition options on every PR and speeds execution by 40%.

Going live

Production Checklist

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

Test regex pattern with all ticket key formats used by your team

Applies when: Always

Verify Jira transition ID works from multiple starting statuses

Applies when: Always

Set error handling to Ignore not Break on Jira module

Applies when: Always

Add webhook verification in GitHub repo settings delivery tab

Applies when: Always

Configure operation limit alerts at 80% of monthly quota

Applies when: High volume

Add rate limiting delay for teams opening 50+ PRs per hour

Applies when: High volume

Troubleshooting

Common errors and how to fix them.

Frequently Asked Questions

Common questions about this workflow.

Analysis

VerdictWhy Make for this workflow

Use Make for this if you need real-time status updates and your team consistently follows branch naming conventions. Make's webhook triggers fire within 30 seconds of PR creation, much faster than Zapier's 5-minute polling. The visual scenario builder makes it easy to add conditional logic for different ticket formats or multiple repositories. Skip Make if your team uses inconsistent branch names - n8n's more flexible text parsing would work better for messy naming patterns.

Cost

This workflow uses 3 operations per PR: GitHub webhook, text parser, and Jira API call. At 100 PRs per month, that's 300 operations monthly. Make's Core plan covers 10,000 operations for $9/month, so you're well within limits. Zapier charges $20/month for the same webhook volume on their Starter plan. n8n cloud costs $20/month for 5,000 executions. Make wins on cost until you hit 200+ PRs monthly.

Tradeoffs

Zapier has a native Jira 'Update Issue' action that handles status transitions without API calls, making setup faster than Make's manual API configuration. n8n offers better regex testing tools and more text parsing functions for complex branch name patterns. But Make's router system handles error cases more elegantly - failed ticket lookups don't break the entire scenario like they do in Zapier. For teams with consistent naming conventions, Make's reliability beats the others' convenience features.

You'll hit rate limits at 150+ API calls per hour if your team opens PRs in bursts during standup or sprint planning. Jira Cloud throttles at 1000 requests per hour per user, but Make's IP-based limits are stricter. Add a 2-second delay module before Jira calls if you see 429 errors. GitHub's webhook delivery can duplicate if your scenario takes longer than 10 seconds to respond - add operation count monitoring to catch runaway scenarios early.

Ideas for what to build next

→
Add Slack Notifications — Send a Slack message to your dev channel when tickets move to In Review, including PR link and reviewer assignments.
→
Auto-assign Jira Tickets — Update the Jira assignee field to match the PR author, ensuring ticket ownership stays aligned with code changes.
→
Track Review Duration — Log start time when tickets enter In Review and calculate average review time when PRs merge or tickets move to Done.