Skip to content

Approval Workflows

Approval Workflows

Approval workflows gate sensitive create, update, and delete operations. Norbital uses a write-then-lock model: the change is applied immediately, the affected records are locked, and an approval request tracks the review. On approval the change simply stands and the locks release; on rejection the records are rolled back to their pre-request version.

Approval config lives on policies
Approvals are configured on mutation grants inside a policy — via approval_config on the grant.

The Versioned Stack

An approval request keeps a stack of approval flows. The active flow is always the last item in the approval_step_nodes history.

This is important because an approval can be rerouted without losing its earlier review history.

Step Statuses

Individual steps move through statuses such as:

  • PENDING
  • APPROVED
  • REJECTED
  • REQUEST_FOR_CHANGE

The overall request can also move through states such as:

  • ONGOING
  • APPROVED
  • REJECTED (also covers a requestor withdrawing their own request)
  • REQUEST_FOR_CHANGE

Lock Types and Lifecycle

To prevent conflicting edits while a request is active, Norbital uses lock records.

The system distinguishes two lock patterns:

  1. Record mutation locks (record_mutation) for create/update edits
  2. Record delete locks (record_delete) for pending deletions

Every record present in the gated mutation payload — the root record plus any related records — is locked, recorded in the request's locked_record_refs.

Locks are created and recalculated while the request is active, then released when the approval reaches a terminal state.

Request for change is not terminal
A request in REQUEST_FOR_CHANGE is still active. Its locks remain in place until the request is resubmitted, rejected, approved, or otherwise resolved.

Supercede Teams

An Approval Config can specify supercede_teams. Members of those teams can bypass the normal step-by-step workflow and act on the whole request immediately.

Reroutes And Path Changes

If the approval path changes while the request is active, Norbital can append a new active flow to the request history and emit an ON_AR_PATH_CHANGE notification event.

This keeps the audit trail intact while still letting the system react to updated approval logic.

Revisions While Locked

The requestor can revise a record that is locked under their own open request. The revised data is re-evaluated from scratch: if it still requires approval the flow restarts (a fresh active flow is appended), and if it no longer requires approval the request auto-resolves as APPROVED.

On Approval and Rejection

Because the change is already live, approval performs no execution — the system simply releases the locks and clears the pending stamp; the change stands. Rejection (including a requestor withdraw) rolls every locked record back to its pre-request version using the record history, then releases the locks.

Delete approvals are fully supported
Approval-gated deletes work the same way: the delete is staged and locked, then finalized on approval or rolled back on rejection.

When To Use Approvals

  • Financial changes above a threshold
  • Changes to records with compliance implications
  • Edits to sensitive master data
  • Mutations that should clearly separate requester and approver roles
  • Use approvals selectively on high-risk mutations only.
  • Pair approvals with clear notifications so reviewers know when action is needed.
  • Test lock behavior on linked or nested records before rolling out a workflow widely.
  • Remember that gated changes go live immediately and are rolled back only on rejection.