Review & Approval

Review & Approval is the workspace’s shared mechanism for routing decisions to reviewers, capturing their input, and recording the final sign-off. It’s not a module of its own kind of record; it’s a cross-cutting actioner that other modules invoke to gate decisions through humans.

A vendor lifecycle transition that needs sign-off uses review-approval. An exception that needs approval uses review-approval. A change request that needs CAB approval uses review-approval. An AI action that requires human approval before executing uses review-approval. The shape is the same; the requesters differ.

When you would reach for this

Review-approval is invoked automatically by other modules when their workflows require sign-off. You configure how it routes when:

A lifecycle transition needs a named approver.
An exception request needs to be reviewed by a risk owner.
A submission package needs internal review before delivery.
An AI action requires human approval per its action policy.
A finding closure needs verification by an independent reviewer.

You don’t directly create review-approval instances yourself. They’re created by the calling module on your behalf, with the routing the calling module configures.

What lives in review-approval

A composite set of records:

Review-approval instance is one decision that’s been routed for sign-off. It carries:

The target (the lifecycle transition, the engagement gate, the public-session task) it gates.
The mode that shapes the gate.
The assignments: which members are reviewers and which are approvers, resolved from responsibilities.
A status walking through active, changes_requested, approved, rejected, cancelled.

Decision is one recorded decision on an instance. A review-stage decision is reviewed or changes_requested; an approval-stage decision is approved or rejected. Comments thread against the instance and can be resolved and reopened.

Modes

The mode the calling module chooses shapes the gate:

Mode	Meaning
`none`	No gate is required.
`auto_approve`	The gate records an approved outcome for the audit trail without a human decision.
`approve_only`	An approval stage runs alone: approvers decide, with no separate reviewer stage.
`review_approve`	A reviewer stage runs first, then an approval stage. Reviewers submit `reviewed` or `changes_requested`; approvers then decide `approved` or `rejected`.

The calling module sets the mode when it invokes review-approval, and the reviewer and approver assignments are resolved from responsibilities. When a reviewer requests changes, the instance enters changes_requested and a fresh attempt can be started, supporting a maker-checker resubmission loop.

A worked example: the procurement marketplace’s review-approval flows

Felipe’s marketplace uses review-approval throughout. A non-exhaustive sample:

Vendor due-diligence → qualified transition. The lifecycle transition invokes review-approval in review_approve mode: the compliance officer and the relevant category lead review, then an approver decides. If an approver rejects, the transition does not happen; the rejection feedback returns to the vendor through the public session.

Vendor qualified → active transition. approve_only mode: the marketplace compliance lead approves. Approval triggers the activation; rejection routes back with rationale.

Buyer kyc-checked → active transition. approve_only mode: the buyer credit assessor (using the responsibility) approves.

Exception request from a vendor for missing certification. review_approve mode: the category lead reviews first, then the compliance officer approves or rejects.

A low-risk, audit-only gate can run in auto_approve mode, recording an approved outcome for the trail without a human decision.

In each case, the calling module decides the mode, supplies the context, and waits for the outcome. The review-approval surface handles the work routing; the calling module receives the outcome and proceeds (or doesn’t).

What you’ll see in the product

Review & Approval lives under Governance → Party → Review & Approval in the workspace, plus an inbox visible to every reviewer/approver showing their pending work.

The Pending list shows every instance currently awaiting review or approval across the workspace, with status, target, and subject.

Inside an instance, you see:

The full context (calling module, target, subject).
The mode and current state.
Review and approval decisions recorded so far, and the comment thread.
Activity history.

Reviewers and approvers see their own pending work in the inbox, with one-click routes into the relevant instance.

Every action is captured in the workspace Audit Log.

Comments and resubmission

Reviewers and approvers can add comments on an instance, reply to them, and resolve or reopen them. When a reviewer requests changes, the instance enters changes_requested and a fresh attempt can be started once the underlying record is updated, so a maker-checker loop runs without losing the prior decision trail.

Cancellation

The calling module can cancel an instance before completion (for example, when the conditions that prompted the request changed). Cancellation is recorded, and a new instance can be started with refreshed context.

Common workflows

Acting on an inbox item

Open the inbox; pick the pending item.
Review the full context: what’s being requested, what’s the subject, what’s the supporting data.
Approve, reject, or request more information.
Capture rationale (required for rejection, optional for approval).
The calling module receives the outcome and proceeds.

Configuring routing (from a calling module’s perspective)

The calling module decides at design time (in the lifecycle, action policy, exception template) what routing to use.
At runtime, the module invokes review-approval with the routing and context.
Outcomes flow back to the module.

Investigating an old decision

From the calling record (e.g., the lifecycle step instance, the closed exception), the linked review-approval instance is visible.
Open the instance to see who decided, when, and on what input.

Overview - the full party governance story.
Lifecycles - transitions often invoke review-approval.
Responsibilities - routing references responsibilities.
Exceptions - exception requests often go through review-approval.
Submissions - internal review before delivery often goes through review-approval.
Action Policies - approval-gated AI actions use review-approval.