Policies & Approvals

Norbital secures operational data with policies assigned to teams. Think in three layers:

• policy grants (collection + action + conditions),
• field and app redaction,
• approval gates on sensitive mutations (write-then-lock).

Policy model

Access is authored as reusable policies, not ad-hoc per-user rows:

• policy — named policy with a grants[] array
• team_policy — assigns a policy to a team
• grant — { collection_name, action, conditions, approval_config? }

Actions are create, read, update, and delete.

If a user belongs to multiple teams, Norbital unions effective grants across those teams. Org admins bypass policy evaluation unless impersonating.

Granular control

1. Row-level conditions

Grant conditions narrow access with template variables such as {{requestor.norbital_id}} and {{original_record.status}}. Partial matches produce reduced access — row filters merged into SQL WHERE clauses.

approval_config on a grant can use the same condition syntax to decide when a mutation needs review — that is the only place expression-style conditions appear in workspace authoring.

2. Attribute-level redaction

Redacted fields are omitted from reads, hidden in UI, and stripped from submitted payloads.

3. App and page redaction

Apps and pages are filtered server-side so users only see navigation they are allowed to access.

Four mutation outcomes

1. Direct — full access; mutation proceeds
2. Reduced — row-filtered access via SQL conditions
3. Gated — write applies immediately, records are stamped and locked, approval request created (write-then-lock)
4. Denied — HTTP 403 when no grant or approval path matches

The policy pipeline

On each mutation:

1. Resolve policies for the user's teams and target collection/action.
2. Evaluate grant conditions against request context.
3. Sanitize redacted fields from the payload.
4. If gated, apply the write, stamp norbital_approval_id, create locks and an approval request.

See Approval Workflows for step nodes, supercede teams, revisions, and rollback behavior.

Recommended config order

1. Define teams and seat types (Builder, Executive, User).
2. Author policies with grants per collection.
3. Assign policies to teams.
4. Add approval configs only on mutations that need review.
5. Test with preview impersonation before go live.