Roles & Policies

Access control in BuildPad DaaS is split across three layers: roles, policies, and permissions.

Roles

A role is a named group (e.g., Editor, Viewer). Users can hold multiple roles simultaneously. Navigate to /roles to create and manage roles.

Each role detail page has three tabs:

• Basic Information — name, icon, parent role
• Users — users currently assigned to this role
• Policies — attach/detach policies (M2M)

Policies

A policy is the source of truth for access flags. Navigate to /policies to manage policies.

Each policy can have:

• Admin access — bypasses all permission checks globally
• App access — grants access to the DaaS Studio
• Delegate access — allows a static-token service account to pass the X-On-Behalf-Of: <user-uuid> header; the service account’s own policies still govern what actions are permitted, but the audit log records the delegated user as the actor (server-to-server only — ignored for cookie/session requests)

Policies are attached to roles (and optionally directly to users). A user’s effective permissions are the union of all policies from all their roles.

Permissions

Each permission rule controls one action on one collection for one policy:

• Actions: create, read, update, delete, share
• Fields: which columns are accessible
• Item filter: JSON filter rule limiting which rows are accessible
• Validation: rules constraining written values
• Presets: default values injected at create time

Permission rules are configured in the permissions table shown directly on the policy detail page (not a separate tab).

Built-in Access Check

GET /api/access               — list all access records
GET /api/policies/me          — effective policies for current user
GET /api/roles/me             — roles for current user
GET /api/permissions/me       — effective permissions for current user