Approval Workflows
Approval workflows gate sensitive create and update operations. When an approval-enabled mutation is triggered, Norbital creates an approval request instead of applying the change directly.
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:
PENDINGAPPROVEDREJECTEDREQUEST_FOR_CHANGE
The overall request can also move through states such as:
ONGOINGAPPROVEDREJECTEDREQUEST_FOR_CHANGESCHEMA_CHANGED
Lock Types and Lifecycle
To prevent conflicting edits while a request is active, Norbital uses lock records.
The system distinguishes three major lock patterns:
- Schema locks for blueprint-sensitive changes
- Record delete locks for protected record links
- Record mutation locks for inline edits to protected records
Locks are created and recalculated while the request is active, then released when the approval reaches a terminal state.
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.
Schema-Changed Status
If the underlying schema changes in a way that invalidates the approval request, the request can be
marked SCHEMA_CHANGED. Treat that as a signal to review and recreate the request path
rather than trying to force it through unchanged.
Post-Approval Execution
When the final step is approved, Norbital can execute the original mutation with an internal bypass so the operation is not blocked by the permission path that required approval in the first place.
create and update. Do not rely on delete approvals to auto-execute the
delete after approval.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
Recommended Operating Rules
- 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.
- Avoid approval-gated delete flows until delete post-approval execution is fully supported.