Stages & Reviews

Stages are the steps of a policy. This page covers how stages decide what blocks a go-live, how approval gates are decided, and how reviewers work. For creating stages, fields, and gates in the Policy Builder, see Policies.

How stages gate a go-live

Each stage lists Gated Resource Types. Gating carries forward: a stage applies to a resource type once that stage or any earlier stage gates it.

Stage 1  Classification    gates: nothing      -> collected, never blocks
Stage 2  Security review   gates: app          -> blocks apps
Stage 3  Final approval    gates: workflow     -> blocks apps and workflows

With this policy on a solution:

• an app in the solution goes live only when the requirements of stages 2 and 3 are satisfied or waived,
• a workflow goes live only when stage 3 is satisfied or waived,
• stage 1 is tracked on the solution (and counts toward its Compliant status) but never blocks.

Every requirement of a stage counts: each required field, plus the stage's gate if it has one. Requirements from all stages count toward the solution's status, whether or not they block anything.

Approvals

An approval gate is decided by the reviewers listed on it.

Reviewers

Each reviewer entry has a type, and in the Policy Builder you pick its target by name:

Type	You pick	Who can decide for this entry
User	A user (search by name or email)	That user
Role	A platform role, for example admin	Anyone with that role
Group	An organization, and optionally one membership role (for example admins only)	Any active member of that organization (with that membership role, when given)

Reviewers are shown by name wherever the gate appears. Through the API, the identifiers are a user ID, a role name, and org:<orgId> or org:<orgId>:role:<memberRole>; a reviewer that names a user, role, or organization that does not exist is rejected.

When approval is requested, every user who can decide for any entry is notified and the gate appears on their Reviews page.

Approval logic

Approval Logic says how many reviewer entries must approve:

Logic	Needs
Any	One entry approved
All	Every entry approved
Majority	More than half of the entries approved (2 of 2, 2 of 3, 3 of 4, 3 of 5)

A role or group entry counts as approved when any user who qualifies for it approves. One person's approval can satisfy several entries they qualify for (for example a user who is listed by ID and also holds a listed role).

• Any denial fails the gate. A reviewer who denies must add a comment. The requester is notified with the comment, and the solution becomes Non-Compliant until approval is requested again and granted. Requesting approval again clears the previous decisions.
• Administrators can decide any approval gate, whether or not they are listed, and their decision settles it: an administrator's approval satisfies the gate and an administrator's denial fails it. An administrator can also reverse a gate that was already decided; the audit log marks this as an admin override.
• A reviewer can change their own vote while the gate is still pending. Once the gate is decided, only an administrator can change it.
• Through the API a reviewer can also record a conditional decision. It is stored with its comments and counts as neither an approval nor a denial.

SLA

SLA Hours sets the expected turnaround. The requirement card shows the hours elapsed since approval was requested next to the SLA, highlighted when the SLA is exceeded.

Requesting approval

On the solution page (or in the blocked go-live window), an approval requirement shows Submit for approval. Clicking it notifies the reviewers and shows Submitted for approval. Waiting for reviewer(s). Progress shows how many entries have approved out of how many are needed, with each entry's decision. After a denial the button appears again so approval can be requested anew.

The Reviews page

Reviewers work from Governance > Reviews (Pending Reviews). It lists the approval gates waiting for a decision that you can decide, grouped by solution (administrators see all of them). Each solution shows how many gates are pending and when the latest was requested. Each gate row shows:

• the gate name, label, and description,
• the kind and the policy it belongs to,
• who requested it and when,
• Submitted for this policy: every other requirement of the same policy on that solution, with its status and value (text and numbers, chosen options, metrics with Met / Not Met, attachments with download links, acknowledgments, guardrail confirmations), so you can see what you are approving.

Approve

Click Approve, add optional comments, and confirm. When enough entries have approved, the gate is satisfied, the requester is notified, and the solution's status updates.

Deny

Click Deny, enter the reason (required), and confirm. The gate fails and the requester is notified with your comment.

When there is nothing to decide, the page shows No pending reviews.

Notifications

Event	Who is notified	Link
Approval requested	Every user who can decide for the gate's reviewer entries	Reviews page
Gate approved	The person who requested approval	The solution
Gate denied	The person who requested approval, with the reviewer's comment	The solution

Notifications appear in the notification bell. When the platform has outgoing email configured, the same notifications are also sent by email.

Designing stages

• Give each stage one purpose, and keep most policies to two to four stages.
• Put information-gathering stages first (gating nothing) and the blocking stages after them.
• Prefer Role or Group reviewers so that one absent person cannot block every release; use User reviewers for named sign-offs.
• All with many reviewers is slow; Majority or Any usually fits.
• Write gate labels and descriptions for the person who is blocked: they are exactly what appears in the blocked go-live window.
• Add help text to fields and labels to evidence gates so people know what to provide.