Access control
Control who can see, change, and approve workspace data, then retain the change history.
Read the technical documentation
What it is
Access control is how you decide who can read, create, update, and delete
operational data and which fields and apps they can see. You author reusable policy rows and select one governing policy on every team; the pod runtime evaluates its grants on every request.
Access is rarely all-or-nothing. Policies support row-level conditions, field redaction, and app-level visibility so each user gets a surface that matches their role.
Policies and approvals
- Reusable
policygrants per collection and action - Exactly one required governing policy per team
- Write-then-lock approval gates on sensitive mutations. Rejection restores the prior version.
Audit logs and revision tracking
Every mutation is tracked. The platform keeps an append-only mutation log and audit events so you can see who changed what and when. These are separate from the operational records users work with day to day.
Collection rows are versioned. Updates append new versions instead of overwriting history. That powers approval rollback (restore the prior version on reject), request-for-change revisions under lock, and a defensible trail for compliance reviews.
What policies govern
Teams can delegate operational work without losing governance. Leaders get policy enforcement, approval workflows, and audit history in the same runtime layer.