Push After Pull Request Creation

Workzone allows administrators to enable or block push operations to a source branch after a pull request (PR) has been created.

Use case: Highly regulated industries or safety-critical systems may prefer blocking pushes to ensure static review of a fixed change set.

Unapprove on Source Branch Commit

Revoke approvals any time a new commit is pushed to the source branch — even if the commit doesn’t change the diff (e.g., a rebase or amend).

• Requires “Push After PR” to be enabled.
• ✅ Enable: All approvals are revoked on any commit.
• 🚫 Disable: Approvals remain, regardless of new commits.

Why this matters: Prevents bypassing approval via silent rebases or minor updates. Ensures reviewers re-validate even subtle changes.

Unapprove on Source Branch Code Change

More targeted than the above — approvals are only revoked if the content of the change set actually changes. Only reviewer approvals of updated files are revoked, not all approvals.

• Requires “Push After PR” to be enabled.
• ✅ Enable: Revoke all approvals if code changes are introduced.
• 🚫 Disable: Approvals are preserved even if code is modified.

Why this matters: Maintains agility while still ensuring that material changes require fresh eyes. Because revocation of approvals is file/path sensitive, only reviewers responsible for updated files need to re-approve. All other given approvals remain and don’t need to be given again. This is a huge time-saver for larger teams.

Unapprove on Target Branch Change

In Bitbucket, pull requests are re-scoped when the destination branch (e.g., develop or main) changes — which can affect the diff or introduce new merge conflicts. This setting ensures that reviewers re-approve PRs in context of the latest destination state.

• ✅ Enable: Any change to the target branch revokes all approvals.
• 🚫 Disable: Target changes do not affect existing approvals.

Use case: Critical in fast-moving branches where merges to develop can alter the final diff of a pull request.

Enforce Merge Conditions Hook

Enable this to apply repository and project wide or global enforcement of Workzone merge conditions before a pull request can be merged.

• ✅ Enable: PR merges are blocked unless all conditions (quotas, signatures, builds) are met.
• 🚫 Disable: Conditions may still apply, but are not strictly enforced by the hook.

Best practice: Combine this with branch permissions and auto-merge user setup to ensure consistent, policy-driven merges across all projects.

Workflow Visibility

Workzone provides a real-time rules overview for every repository or project. This includes:

• Reviewer group rules
• Merge condition logic
• Digital signature policies
• Workflow hook settings

Teams can refer to this ruleset to understand exactly how their pull request lifecycle is governed, making compliance and onboarding far easier.

Pull request merge status report

Each pull request has detailed Workzone merge condition report that details the approval status of the pull request, including which conditions are satisfied, which are not yet satisfied and which approvals, task completion or required build results are missing for the merge condition to pass.