Why should I use P4 Code Review workflow?

Workflows let you define and enforce rules that control how changelists and reviews move through your project.

By default, P4 Code Review has one workflow ready to go. This is a Global Workflow, which applies across every branch and project in the platform. Use the Global Workflow to ensure basic company policies are followed by every project). There can only be one global workflow in P4 Code Review.

The same workflow can be reused across multiple areas. This means when you update a workflow, it is updated everywhere it has be applied.

Without workflows, the review process is largely advisory, and team members can work in different ways. As projects grow, this can lead to inconsistent processes and reduced quality. Workflows ensure that all reviews follow the same standards, help teams enforce agreed‑upon rules, and improve both stability and delivery speed as projects scale.

Example

A typical project will have the following branches:

A workflow can be applied to each of these branches, with rules tailored to its branch type.

Development branch example

A development branch is typically fast‑moving and intentionally flexible. It allows teams to add new features and content quickly, even if this results in temporary instability. Consider the following configuration for a development branch workflow:

  • Allow both post‑commit and pre‑commit reviews.

  • Only one reviewer is usually required to approve a review.

Main branch example

A main branch requires tighter control than the development branch because it should remain stable as the project moves toward release. The workflow should enforce stricter review requirements to ensure changes are thoroughly checked before they are committed. A suitable configuration typically includes:

  • Pre‑commit reviews only: All changelists must be shelved with an associated review before they can be submitted.

  • Project‑member approval: Only votes from project members count toward approval.

  • Stricter approval threshold: Two project reviewers must approve the review to trigger automatic approval.

  • Content verification: A changelist can only be committed if its content matches the content of the approved review.

Release branch example

A release branch must be tightly controlled to protect a stable codebase as the product approaches release. Only essential, high‑priority fixes should be allowed. To enforce this level of protection, senior project members act as moderators who control which changes are approved. Moderators are added to the branch from the project branch settings pane.

A suitable workflow configuration typically includes:

  • Pre‑commit reviews only: All changelists must be shelved with an associated review before submission.

  • Restricted approval: Only senior project members may vote on the review.

  • Moderator control: Moderators serve as final gatekeepers and are the only users who can approve or reject a review after required reviewers have voted.

  • Content verification: A changelist can only be committed if its content exactly matches the approved review.

  • Quality safeguards: Review approval is blocked if designated tests fail.