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 requesting module and record (the lifecycle transition, the exception, the submission).
• The subject (the party, the control, the document, the decision).
• The routing: which reviewers, which approvers, in what sequence.
• A status walking through pending, under-review, approved, rejected, withdrawn, expired.
• A deadline (optional).

Review record is one reviewer’s input on an instance. Multiple review records can attach to one instance (sequential or parallel).

Approval record is the final sign-off (or rejection) on the instance.

Routing shapes

Review-approval supports several routing shapes:

The calling module configures the routing shape when it invokes review-approval.

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 with parallel-all routing to two reviewers: the compliance officer and the relevant category lead. Both must approve. If either rejects, the transition does not happen; the rejection feedback returns to the vendor through the public session.

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

Buyer kyc-checked → active transition. Single approver: the buyer credit assessor (using the responsibility).

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

Buyer credit limit increase request. Quorum routing: 2-of-3 among the credit team must approve.

AI action policy on the “propose suspension of vendor” capability (if such a Copilot exists). Single approver: the marketplace compliance lead.

In each case, the calling module decides the routing, 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, deadline, requesting record, subject.

Inside an instance, you see:

• The full context (calling module, record, subject).
• The routing shape and current state.
• Review records added so far.
• The deadline.
• 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.

Deadlines and escalation

Instances can carry a deadline. As the deadline approaches, the system surfaces the pending item in the inbox of the routed reviewers and (optionally) escalates to a backup or alerts a defined supervisor.

A missed deadline doesn’t auto-decide; the decision still requires a human. But the missed deadline is visible and audited, which often is enough to trigger action.

Withdrawal and reissuance

The calling module can withdraw an instance before completion (e.g., the conditions that prompted the request changed). Withdrawal is recorded with rationale. A new instance can be reissued with refreshed context.

Common workflows

Acting on an inbox item

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

Configuring routing (from a calling module’s perspective)

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

Investigating an old decision

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

Related

• 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.