Roles, the permission catalog, the audit log, and the frontend builder-gating primitive.
Permissions
FastYoke ships role-based access control with a fixed catalog of permissions and four built-in system roles. Tenant admins can also define their own custom roles by selecting any subset of the catalog. Every API call and every authoring surface checks the calling user's effective permissions on the way in.
Tenant scope
Roles and role assignments are tenant-scoped. A user invited to two tenants gets a separate role assignment in each. There is no cross- tenant role sharing and no cross-tenant permission inheritance.
The four system roles
| Role | What it can do |
|---|---|
system:admin | Everything — the only role that can create, edit, and delete custom roles, manage users, manage billing, and configure SSO. |
system:manager | Owns the full content surface: FSM schemas, jobs, entities, forms, files, apps, PDFs, pages, projects, branding, themes, and connections. Cannot manage users or roles, cannot manage billing, cannot manage SSO. |
system:member | Day-to-day operations: read everywhere, plus create / update entities, transition jobs, edit form drafts, upload files. Designed for operators who run the workflow without authoring it. |
system:viewer | Read-only on every surface. Sees the audit log too (read-only is read-only — there is no surface a viewer can change). |
Auditor role (Compliance Yoke)
The Auditor role is a fifth built-in system role created on demand when you invite an external auditor to a Compliance Yoke engagement. It is scoped to read engagement evidence, pull samples, and download the OSCAL and ZIP exports — nothing else. See Auditor Room.
Users are assigned roles at sign-in — see Sign-in flows for the local, OTP, and AuthKit paths and what role each one establishes.
Custom roles
An admin opens Users → Roles, creates a new role, names it, checks the permissions it should hold, and saves. Custom roles inherit nothing implicitly — every permission is an explicit checkbox. A user can be assigned a system role and a custom role; their effective permissions are the union of both.
Effective permissions
A user's effective set is the union of every role assigned to
them. Permissions are additive — there is no deny-list, no negative
grant. A user with system:viewer plus a custom role that adds
forms.update can edit form drafts.
See also
- The full permission catalog — every id, grouped by domain.
- The role-change audit log — what gets recorded when an admin changes a role assignment.
- The builder-gating primitive — what
RequirePermissiondoes in the frontend.