Stages & Reviews

Policy stages define the individual steps within a governance workflow. Each stage collects information through form fields, can require a gate (such as a reviewer approval), and can block selected resource types from deploying until its requirements are satisfied. Reviewers act on pending approvals from the Governance > Reviews page.

Stage Structure

Each stage within a policy contains:

Field	Description
name	Descriptive name (e.g., "Security Review", "Technical Approval")
description	What this stage covers
order	Sequential position in the workflow
isRequired	Whether this stage is required or optional
fields	Custom form fields for data collection
gate	Optional gate: input, acknowledgment, approval, threshold, evidence, or guardrail
gatedResourceTypes	Resource types this stage blocks from deploying until its requirements are satisfied

Custom Fields

Each stage can define custom form fields. Required fields become compliance requirements: they must be submitted before the solution is compliant, and they block deploys of any resource type gated by their stage.

Field Types

Type	Use Case	Example
text	Short answers, identifiers	"Security scan ID"
textarea	Detailed responses, justifications	"Describe the changes"
richtext	Long-form documentation	"Privacy Impact Assessment"
radio	Single selection from options	"Risk Level: Low / Medium / High"
checkbox	Multiple selection checklist	"Compliance items verified"
dropdown	Single selection dropdown	"Target environment"
multiselect	Multiple selection	"Applicable frameworks"
file	Evidence documents, reports	"Security scan report"
number	Metrics, scores, counts	"Model accuracy score (0-100)"
date	Target dates, deadlines	"Expected completion date"
datetime	Scheduled events	"Deployment window"
url	External evidence links	"Link to test dashboard"
email	Contact information	"Responsible engineer's email"

Field Properties

Property	Description
name	Machine-readable identifier (used in data storage)
label	Human-readable display label shown in the form
required	Whether the field counts as a compliance requirement
helpText	Guidance text displayed with the field
placeholder	Placeholder text shown in empty fields
options	Value/label pairs for selection fields
validation	Min/max values, min/max length, regex pattern, custom error message

Reviewers

Approval gates route to reviewers. When a team member submits an approval gate, every configured reviewer is notified and the gate appears in their Governance > Reviews inbox.

User Reviewers

Assign a specific user by their user ID. Only that exact user can approve the gate.

{ type: "user", identifier: "<userId>" }

Best for: Designated reviewers, specific subject-matter experts, compliance officers.

Role-Based Reviewers

Assign by role name. Any user who holds the specified role can approve.

{ type: "role", identifier: "admin" }

Best for: Flexible team assignments where any team member with the right role can approve. Team changes don't require policy updates.

Group Reviewers

Assign by organization membership. The system checks for an active membership in the organization.

Organization format:

{ type: "group", identifier: "org:<orgId>" }

Organization + membership role format:

{ type: "group", identifier: "org:<orgId>:role:<memberRole>" }

Best for: Cross-team approvals, committee reviews, organization-wide compliance requirements.

Approval Logic

When a gate has multiple reviewers, the Approval Logic setting controls the quorum:

• Any, a single approval satisfies the gate
• All, every reviewer must approve
• Majority, more than half of the reviewers must approve

A single denial fails the gate regardless of logic.

Admin Override

Administrators can always approve or deny any approval gate regardless of reviewer assignments, and can overturn a gate that has already been decided. Overturned decisions are marked distinctly in the audit trail so they are easy to find during compliance review. Administrators can also waive any requirement entirely.

The Reviews Page

Reviewers work from Governance > Reviews (/governance/reviews). The page lists every solution with approval gates awaiting your review, grouped by solution. Each pending gate shows:

• The gate name, label, and description
• The policy it belongs to
• Who submitted it and when
• The submitted values (text, metrics with met/not-met, attachments, acknowledgments, guardrail verification)

Approve

Click Approve, optionally add comments, and confirm. When the quorum is reached the gate becomes satisfied, the submitter is notified, and the solution status recomputes.

Deny

Click Deny and provide a comment; a comment is required when denying. The gate fails, the submitter is notified with your comment, and the solution becomes non-compliant until the gate is resubmitted and approved.

Each decision is stored as an approval record with the reviewer, decision, comments, and timestamp.

Notifications

The governance notification system keeps stakeholders informed of approval activity:

Event	Recipients
Approval gate submitted	Every configured reviewer for the gate
Gate approved	The submitter
Gate denied	The submitter (with the reviewer's comment)

Notifications appear in the in-app notification bell and link to the relevant Reviews or Solution page. When the platform has outbound email configured, reviewers and submitters also receive an email.

Deploy Gating

Stages control deployment through their Gated Resource Types. When a stage gates a resource type, every workload of that type in the solution is blocked from deploying until all of the stage's required fields and its gate are satisfied or waived.

Gating is cumulative across stages: once a stage gates a resource type, later stages' requirements also apply to it. This lets you phase enforcement:

Stage 1 (Classification)   gates: nothing     → collect data, never block
Stage 2 (Security Review)  gates: app         → apps blocked until stages 2+ complete
Stage 3 (Final Approval)   gates: app, workflow

When a blocked deploy is attempted, the deploy dialog lists the pending requirements and lets the team complete them inline, then retry. See Enforcement for the full flow.

Stage Workflow Patterns

Sequential Review

Order stages so information gathering comes first and approvals come last:

Stage 1 (Security Review) → Stage 2 (Technical Approval) → Stage 3 (Business Sign-off)

Best for: Linear approval processes where each stage builds on the previous one.

Multi-Reviewer Gate

A single approval gate with multiple reviewers and all or majority logic:

Stage 1: Approval gate [Security Lead + Compliance Officer + Privacy Officer], logic: majority

Best for: Committee decisions, cross-functional reviews requiring multiple perspectives.

Progressive Gating

Use per-stage gated resource types to tighten enforcement as the workflow progresses: early stages collect information without blocking anything, later stages gate the resource types that matter.

Best for: Introducing governance without halting in-flight work; teams see requirements before blocking begins.

Best Practices

Design Focused Stages

• Each stage should have a single, clear purpose
• Avoid combining unrelated reviews in one stage
• Break complex reviews into smaller, focused stages
• Use descriptive stage names that indicate what is being reviewed
• Keep the number of stages manageable (2-4 stages covers most workflows)

Choose Appropriate Reviewers

• Use role-based reviewers for flexibility as team membership changes
• Use user-specific reviewers for specialized reviews requiring particular expertise
• Use group reviewers for organization-wide compliance requirements
• Keep the required quorum manageable; all with many reviewers slows the process
• Set an SLA Hours value on approval gates so reviewers can see when a review is overdue

Provide Clear Instructions

• Add help text to every form field explaining what is expected
• Use the gate description on acknowledgment gates as the exact statement being acknowledged
• Add labels to evidence gates describing each document to upload
• Use URL fields to link to relevant documentation or dashboards

tip

Start with simple 2-3 stage policies and add complexity as governance needs mature. Most compliance requirements can be addressed with well-designed sequential stages.