Intermediate~15 min setupDeveloper Tools & Project ManagementVerified April 2026
GitHub logo
Jira logo

How to sync PR to Jira status with Pipedream

Automatically move Jira tickets to In Review when a pull request is opened with 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.

Best for

Dev teams who track work in Jira and need ticket status to reflect actual development progress

Not ideal for

Teams that don't use branch naming conventions or prefer manual ticket management

Sync type

real-time

Use case type

sync

Real-World Example

πŸ’‘

A 20-person dev team at a fintech startup uses this to automatically move Jira tickets to In Review when PRs are opened. Before automation, developers forgot to update ticket status 40% of the time, causing confusion for product managers tracking sprint progress. Now status changes happen within 5 seconds of PR creation.

What Will This Cost?

Drag the slider to your expected monthly volume.

/mo
505005K50K

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

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 Pipedream

Copy the pre-built Pipedream blueprint and paste it straight into Pipedream. 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.

Admin access to your GitHub repository to install webhooks
Jira API token with permission to update issues in your project
Consistent branch naming convention that includes Jira ticket keys
Knowledge of your Jira workflow transition IDs for status changes

Field Mapping

Map these fields between your apps.

FieldAPI Name
Required
Issue Keykey
Transition IDtransition.id
4 optional fieldsβ–Έ show
PR Titlecomment.body
PR URLcomment.body
Authorassignee.name
Repositoryproject.key

Step-by-Step Setup

1

Pipedream Dashboard > Workflows > New

Create new Pipedream workflow

Go to pipedream.com and click New Workflow in the top navigation. You'll land on the workflow builder with a blank canvas. The interface shows Steps on the left and the configuration panel on the right. Click the Add a Trigger button to start building.

  1. 1Click 'New Workflow' in the top navigation
  2. 2Click 'Add a Trigger' in the workflow builder
  3. 3Search for 'GitHub' in the app selector
  4. 4Select 'New Pull Request' from the trigger list
βœ“ What you should see: You should see the GitHub trigger configuration panel with webhook setup options.
2

Trigger Configuration > GitHub > New Pull Request

Configure GitHub webhook trigger

Connect your GitHub account by clicking Connect Account. Select your repository from the dropdown - this determines which repo will send webhook events. Choose 'Pull Request opened' as the event type. Pipedream automatically creates a webhook endpoint that GitHub will call.

  1. 1Click 'Connect Account' and authorize Pipedream
  2. 2Select your target repository from the dropdown
  3. 3Choose 'opened' from the pull request events
  4. 4Click 'Save' to create the webhook
βœ“ What you should see: You should see a green 'Connected' status and a unique webhook URL generated by Pipedream.
⚠
Common mistake β€” The webhook only captures events after creation - it won't retroactively process existing PRs.
Pipedream
+
click +
search apps
GitHub
GI
GitHub
Configure GitHub webhook tri…
GitHub
GI
module added
3

Workflow Builder > Add Step > Code

Add code step to extract Jira ticket key

Click Add a Step below the trigger and select Code. This Node.js step will parse the branch name to find Jira ticket keys. The GitHub webhook payload includes the branch name in the head.ref field. You'll write JavaScript to extract patterns like PROJ-123 from branch names.

  1. 1Click '+ Add a Step' below the GitHub trigger
  2. 2Select 'Code' from the step types
  3. 3Choose 'Run Node.js code'
  4. 4Name the step 'Extract Jira Key'
βœ“ What you should see: You should see a code editor with a default export async function template.
⚠
Common mistake β€” Make sure your team follows consistent branch naming with Jira keys or this won't work.

This code extracts Jira ticket keys from branch names and handles multiple project prefixes. Paste this in your Node.js code step to replace the default template.

JavaScript β€” Code Stepexport default defineComponent({
β–Έ Show code
export default defineComponent({
  async run({ steps, $ }) {
    const branchName = steps.trigger.event.pull_request.head.ref;

... expand to see full code

export default defineComponent({
  async run({ steps, $ }) {
    const branchName = steps.trigger.event.pull_request.head.ref;
    const prTitle = steps.trigger.event.pull_request.title;
    const prUrl = steps.trigger.event.pull_request.html_url;
    const author = steps.trigger.event.pull_request.user.login;
    
    // Match Jira ticket patterns like PROJ-123, AUTH-456, etc.
    const jiraKeyRegex = /([A-Z]{2,}-\d+)/g;
    const matches = branchName.match(jiraKeyRegex);
    
    if (!matches || matches.length === 0) {
      console.log(`No Jira key found in branch: ${branchName}`);
      return $.flow.exit('No Jira ticket key found in branch name');
    }
    
    // Take the first match if multiple keys exist
    const ticketKey = matches[0];
    
    return {
      ticket_key: ticketKey,
      pr_title: prTitle,
      pr_url: prUrl,
      author: author,
      branch_name: branchName,
      comment: `PR opened by ${author}: ${prTitle} - ${prUrl}`
    };
  }
});
4

Code Step > Editor

Write ticket key extraction logic

In the code editor, write logic to parse the branch name and extract Jira ticket keys. The branch name comes from steps.trigger.event.pull_request.head.ref. Use a regex pattern to match your Jira project key format. If no ticket key is found, the workflow should exit early to avoid unnecessary API calls.

  1. 1Clear the default code in the editor
  2. 2Write regex logic to extract ticket keys
  3. 3Add validation to check if a key was found
  4. 4Return the extracted key or exit if none found
βœ“ What you should see: The code should output the extracted Jira ticket key when you test with sample data.
5

Workflow Builder > Add Step > Jira

Add Jira API step

Add another step and search for Jira in the app directory. Choose 'Update Issue' as the action since you're changing the ticket status. You'll need to connect your Jira instance using your email and an API token. The step configuration will show fields for issue key, transition ID, and other update parameters.

  1. 1Click '+ Add a Step' below the code step
  2. 2Search for 'Jira' and select it
  3. 3Choose 'Update Issue' from the actions
  4. 4Click 'Connect Account' to add Jira credentials
βœ“ What you should see: You should see the Jira step configuration with fields for issue key and transition details.
⚠
Common mistake β€” You need Jira admin permissions to create API tokens - ask your Jira admin if you can't generate one.
6

Jira Step > Account Connection

Configure Jira connection

Enter your Jira site URL without trailing slash, your email address, and an API token. Get the API token from your Atlassian account settings under Security > API tokens. Test the connection to make sure Pipedream can reach your Jira instance. Some corporate firewalls block external webhook calls.

  1. 1Enter your Jira URL (e.g., company.atlassian.net)
  2. 2Enter your Jira email address
  3. 3Paste your API token from Atlassian account
  4. 4Click 'Test' to verify the connection
βœ“ What you should see: You should see a green 'Connected' badge indicating successful authentication.
7

Jira Step > Issue Key Field

Map issue key from code step

In the Issue Key field, reference the output from your code step. Click the + button next to the field to see available data. Navigate to your code step output and select the ticket key variable. This creates a dynamic reference that uses the extracted key for each PR.

  1. 1Click the '+' button next to Issue Key field
  2. 2Expand the code step output section
  3. 3Select the ticket key variable you returned
  4. 4Verify the reference shows in the field
βœ“ What you should see: The Issue Key field should show a dynamic reference like {{steps.extract_jira_key.ticket_key}}.
⚠
Common mistake β€” If the ticket key doesn't exist in Jira, the workflow will fail - add error handling in production.

This code extracts Jira ticket keys from branch names and handles multiple project prefixes. Paste this in your Node.js code step to replace the default template.

JavaScript β€” Code Stepexport default defineComponent({
β–Έ Show code
export default defineComponent({
  async run({ steps, $ }) {
    const branchName = steps.trigger.event.pull_request.head.ref;

... expand to see full code

export default defineComponent({
  async run({ steps, $ }) {
    const branchName = steps.trigger.event.pull_request.head.ref;
    const prTitle = steps.trigger.event.pull_request.title;
    const prUrl = steps.trigger.event.pull_request.html_url;
    const author = steps.trigger.event.pull_request.user.login;
    
    // Match Jira ticket patterns like PROJ-123, AUTH-456, etc.
    const jiraKeyRegex = /([A-Z]{2,}-\d+)/g;
    const matches = branchName.match(jiraKeyRegex);
    
    if (!matches || matches.length === 0) {
      console.log(`No Jira key found in branch: ${branchName}`);
      return $.flow.exit('No Jira ticket key found in branch name');
    }
    
    // Take the first match if multiple keys exist
    const ticketKey = matches[0];
    
    return {
      ticket_key: ticketKey,
      pr_title: prTitle,
      pr_url: prUrl,
      author: author,
      branch_name: branchName,
      comment: `PR opened by ${author}: ${prTitle} - ${prUrl}`
    };
  }
});
GitHub fields
title
body
state
html_url
user.login
available as variables:
1.props.title
1.props.body
1.props.state
1.props.html_url
1.props.user.login
8

Jira Step > Transition Configuration

Set transition to In Review

Find the transition ID for moving tickets to In Review status. Go to your Jira project settings > Workflows > View workflow to see available transitions. Each transition has a numeric ID. Common IDs are 21 for In Review or 31 for In Progress, but these vary by Jira setup.

  1. 1Open your Jira project in another tab
  2. 2Go to Project Settings > Workflows
  3. 3Note the transition ID for 'In Review'
  4. 4Enter this ID in the Transition field
βœ“ What you should see: The Jira step should show the correct transition ID that moves tickets to In Review status.
9

Workflow Builder > Test Button

Test the complete workflow

Click Test at the top of the workflow to run it with sample data. Create a test branch with a Jira ticket key in the name, then open a PR. Check that the workflow triggers, extracts the key correctly, and updates the Jira ticket status. Review the execution log for any errors.

  1. 1Click 'Test' in the workflow header
  2. 2Create a test PR with ticket key in branch name
  3. 3Watch the workflow execution in real-time
  4. 4Check your Jira ticket for status change
βœ“ What you should see: The workflow should complete successfully and your Jira ticket should move to In Review status.
⚠
Common mistake β€” Test with a real ticket key - the workflow will fail if the ticket doesn't exist in Jira.
Pipedream
β–Ά Deploy & test
executed
βœ“
GitHub
βœ“
Jira
Jira
πŸ”” notification
received
10

Workflow Builder > Deploy Button

Deploy workflow

Once testing works, click Deploy to activate the workflow for all future PRs. The webhook will now process every PR opened in your connected repository. You can monitor execution history in the workflow dashboard and see success/failure rates over time.

  1. 1Click 'Deploy' in the workflow header
  2. 2Confirm deployment in the modal dialog
  3. 3Check that status changes to 'Active'
  4. 4Monitor the execution log for live events
βœ“ What you should see: The workflow status should show 'Active' and it will process new PRs automatically.

Going live

Production Checklist

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

Troubleshooting

Common errors and how to fix them.

Frequently Asked Questions

Common questions about this workflow.

Analysis

VerdictWhy n8n for this workflow

Use Pipedream for this if your team writes custom branch parsing logic or needs complex Jira field updates beyond basic status changes. The Node.js code step lets you handle multiple ticket key formats, validate ticket existence, and add custom error handling. Pipedream's instant webhook processing means tickets update within 5 seconds of PR creation. Skip Pipedream if you need this workflow to run inside your corporate firewall where external services can't reach your Jira instance.

Cost

The math works out to roughly 2 credits per PR (1 for the trigger, 1 for the Jira update). At 200 PRs per month, you'll use 400 credits costing about $2. Make charges €9/month for the same volume on their Core plan. Zapier would cost $20/month at this volume since you'd need their Professional plan. Pipedream is the cheapest option here until you hit 2000+ PRs monthly.

Tradeoffs

Make handles this workflow cleaner with its built-in text parsing tools - no regex required. Zapier's Code by Zapier works but limits you to 10 seconds execution time. N8N gives you similar Node.js capabilities if you're self-hosting, plus better debugging tools. Power Automate integrates better if you're already in the Microsoft ecosystem. But Pipedream wins on webhook reliability - GitHub webhooks hit Pipedream endpoints faster and more consistently than other platforms.

You'll hit rate limits around 100 rapid PRs per hour due to Jira's API restrictions. The webhook sometimes delivers duplicate events if GitHub retries failed calls - add deduplication logic using PR numbers. Branch names with special characters break the regex matching, so test with your actual naming conventions. Some corporate Jira instances block external API calls entirely, killing the workflow even with valid credentials.

Ideas for what to build next

  • β†’
    Add reverse sync for PR merges β€” Create a second workflow that moves tickets to Done when PRs are merged to main branch.
  • β†’
    Include PR details in Jira comments β€” Enhance the workflow to add PR title, author, and link as comments on the Jira ticket.
  • β†’
    Handle multiple ticket keys per branch β€” Modify the code to process multiple Jira keys if your branch names reference several tickets.

Related guides

Was this guide helpful?
← GitHub + Jira overviewPipedream profile β†’