Move a Jira issue when its pull request is approved

Jira Cloud can move an issue when a pull request is created, merged or declined, but not when it's approved. This page covers what Jira can do on its own, Atlassian's webhook workaround for Bitbucket, GitHub and GitLab, and where that workaround falls short.

Checked against Atlassian's, GitHub's and GitLab's documentation on 29 September 2026. Atlassian now calls issues "work items" and projects "spaces"; this page keeps the older names.

What Jira can do on its own

The workflow triggers list also has "Review" events, such as "Review submitted for approval". Those come from Crucible, Atlassian's older code review tool, not from pull requests.

People have asked for the missing trigger for years. JRACLOUD-71798, "Add a 'Pull request approved' to workflow triggers", has 325 votes and has been gathering interest since 27 March 2019. The automation version, JRACLOUD-81389, has 26.

Atlassian's workaround for Bitbucket

Atlassian's knowledge base article connects a Bitbucket webhook to an automation rule. It needs the issue key in every pull request's title.

1. In Jira, create an automation rule with the Incoming webhook trigger, and copy the webhook URL it gives you.
2. Add a branch for the issue whose key is in the pull request's title, with this JQL:
   key = {{webhookData.pullrequest.title.match("(\b[A-Z]+-\d+\b)")}}
3. Inside the branch, add a Transition action to the status you want.
4. In Bitbucket, open the repository's settings, add a webhook with the URL from step 1, and choose the pull request Approved trigger.

What to watch for

• It runs on the first approval. Bitbucket sends the Approved event each time a user approves, so the issue moves on the first approval even if your team wants two. As written, the rule doesn't count approvals or check whose they are: the author's own, a bot's, or one given before the latest push all move the issue.
• Nothing moves it back. If someone removes their approval, Bitbucket sends a separate "Approval removed" event, which this rule ignores.
• One pull request at a time. An issue with pull requests in three repositories moves when the first of them gets an approval.
• It can't block. An automation rule moves issues; it can't stop someone moving an issue by hand before the code is approved. That takes a workflow validator.

GitHub and GitLab

The same rule works with other code hosts' webhooks, with a condition on the event:

• GitHub sends a pull_request_review event for every submitted review, approving or not. Add an If: smart values condition that {{webhookData.review.state}} equals approved, and find the key in {{webhookData.pull_request.title}}. GitHub's documentation uses the same test for "a pull request is approved".
• GitLab merge request events send the action approval when one user approves and approved when the merge request is "fully approved by all required approvers". Check that {{webhookData.object_attributes.action}} equals approved. GitLab is the only one of the three that tells you when the required number is reached.

Blocking the merge instead

Bitbucket's minimum number of approvals merge check works on every plan, but only Bitbucket Premium stops the merge; on other plans people see a warning and can still merge. Either way it guards the merge in Bitbucket, not the issue's status in Jira.

Where Pull Request Status Sync fits

I built Pull Request Status Sync for Jira for teams that need more than the workaround. It reads pull requests on Bitbucket Cloud, GitHub and GitLab, read-only, and:

• moves an issue on only when every linked pull request has the number of approvals you set;
• doesn't count the author's own approval, approvals from before the latest commit, bots you list, or approvals from an earlier review round;
• finds an issue's pull requests in every repository, by the key in the title, the branch name (Bitbucket) or the description (GitHub, GitLab);
• can block moving an issue by hand until its pull requests are approved, with a workflow validator (off by default);
• lists issues whose status disagrees with their pull requests.

The app is waiting for Atlassian's Marketplace approval, so it can't be installed from the Marketplace yet. It will be free for up to 10 users (pricing).