Permissions & Approvals

Norbital secures operational data with a team-based model. As a configurator, you should think about three layers working together:

• route permissions,
• field redaction,
• approval workflows for sensitive mutations.

Role-Based Access Control (RBAC)

Access is granted by assigning teams to collection routes such as list, view, create, update, and delete.

If a user belongs to multiple teams, Norbital evaluates the combined access from those teams rather than forcing you to pick one role.

Granular Control

1. Row-Level Conditions

Permissions can be narrowed with record-level conditions so a team only sees or mutates the subset of records relevant to them.

Use these conditions when access depends on the record itself, such as region, owner, department, or status.

2. Attribute-Level Redaction

If a field is redacted for a user:

• it is omitted from reads,
• it is hidden from rendered table and form surfaces,
• Dynamic UI nodes that reference it can be replaced with a redacted placeholder,
• restricted fields are stripped from submitted payloads.

3. App and Page Redaction

Apps and pages are also filtered server-side. Users only receive the app navigation and page definitions they are allowed to access.

The Permission Layer Pipeline

When a user attempts a mutation:

1. Norbital evaluates the user's effective team permissions.
2. It checks any configured row-level conditions.
3. It sanitizes restricted fields from the payload.
4. If approval is required, it creates an approval request instead of applying the write directly.

For updates, blocked fields are preserved rather than nulled out, which protects restricted data when a user submits a partial payload.

Dynamic UI And Redaction

Direct form bindings remain redaction-aware. At the same time, Dynamic UI host queries can bypass field masking so dashboards and aggregate views can still compute from full data when that is the intended behavior.

This means you should use direct form bindings for permission-sensitive form surfaces and reserve host queries for carefully designed reporting or contextual views.

Task Access

Tasks use their own access model and are simpler than collection permissions:

• Admins can see all tasks unless they are impersonating.
• Non-admins can see tasks assigned directly to them.
• Non-admins can also see tasks assigned to their teams.

Linked record access is still enforced separately from task visibility.

Recommended Configuration Order

1. Grant the minimum route access each team needs.
2. Add row-level conditions where the access boundary depends on record data.
3. Redact sensitive fields that should never appear for that team.
4. Add approvals only to the mutations that carry financial, compliance, or operational risk.