Permissions & Roles
Last updated: March 2026
Configure role-based access control (RBAC) with granular permission scopes, field-level security, role inheritance, and audit logging.
On this page
Permission Model Overview
Webooto uses a role-based access control (RBAC) model to govern what each user can see and do across the platform. Every permission is defined as a combination of an action, a resource type, and a scope, giving you fine-grained control over access at every level.
Roles are the primary grouping mechanism for permissions. Each role has a name, an optional description, and an isActive flag. Roles can be marked as system roles (isSystem), which are built-in and cannot be deleted. Custom roles can be created to match your organizational structure.
Role inheritance is supported through the parentRoleId field. A child role automatically inherits all permissions from its parent, and you can layer additional permissions or restrictions on top. This lets you build a hierarchy - for example, a "Manager" role that extends a "Member" role with extra capabilities.
There are six resource types that permissions can target: system, entity, page, media, user, and role. Each resource type represents a distinct area of the platform, and permissions are always scoped to a specific resource type.
The available permission actions are: create, read, update, delete, execute, publish, and * (all). The wildcard action grants every action on the targeted resource type, which is useful for administrative roles.
System roles are protected and cannot be deleted or renamed. They serve as the foundation of the permission model and ensure baseline access is always available.
Creating Roles
Custom roles let you tailor access to your exact requirements. You can create as many roles as needed and optionally base them on an existing role through inheritance.
Navigate to Roles
Open the workspace settings and select the "Roles & Permissions" section from the sidebar.
Create a new role
Click "Add Role" and provide a name and an optional description. If you want the role to inherit permissions from an existing role, select a parent role using the parentRoleId dropdown.
Assign permissions
Use the CRUD matrix editor to visually toggle permission actions (create, read, update, delete, execute, publish) for each resource type. Set the appropriate scope for every action to control how broadly the permission applies.
Configure field-level security
For entity-level permissions, optionally define allowedFields or deniedFields to restrict which fields users in this role can access. You can also add permission conditions for dynamic, context-aware rules.
Activate and save
Toggle the isActive flag to enable the role, then save. The role is now available for assignment to users.
Start with a parent role that covers common permissions, then create child roles that add or restrict specific capabilities. This reduces duplication and makes the hierarchy easier to maintain.
CRUD Matrix & Scopes
The CRUD matrix editor provides a visual grid where you can toggle permission actions for each resource type and assign a scope to each action. Scopes determine the breadth of access a permission grants.
When configuring permissions, select the scope that matches the intended reach. Scopes are hierarchical - a broader scope always includes the access of narrower scopes.
| Scope | Value | Description |
|---|---|---|
| None | none | No access. The action is explicitly denied for this resource type. |
| Own | own | Access is limited to records created by the current user. |
| Team | team | Access extends to records owned by any member of the user's team. |
| Application | application | Access covers all records within the current application boundary. |
| Tenant | tenant | Access spans all records within the workspace (tenant), regardless of ownership. |
| Global | * | Unrestricted access across all workspaces. Reserved for super-admin scenarios. |
The global (*) scope bypasses all workspace boundaries. Only assign it to super-admin roles that genuinely require cross-tenant access.
Field-Level Security
Beyond action-and-scope permissions, Webooto supports field-level security on entity resources. This lets you control exactly which fields a role can read or write, even when the role has broad entity access.
Each permission entry can include an allowedFields list (whitelist) or a deniedFields list (blacklist). When allowedFields is set, only the specified fields are accessible - all others are hidden. When deniedFields is set, every field is accessible except the listed ones. You should use one approach per permission, not both.
Permission conditions add another layer of dynamic control. Conditions are evaluated at runtime and can reference the current user, the target record, or contextual data. For example, you can create a condition that allows editing a record only if its status is "draft" or if the user belongs to a specific department.
Field-level security and conditions are enforced server-side, so they cannot be bypassed from the client. The UI automatically hides or disables fields the current user cannot access, providing a seamless experience.
If both allowedFields and deniedFields are configured on the same permission, allowedFields takes precedence and deniedFields is ignored. Pick one strategy per permission to avoid confusion.
Role Assignment & Audit
Once roles are configured, you assign them to individual users. A user can hold multiple roles, and the effective permission set is the union of all assigned roles (most permissive wins). Role assignments can include an optional expiration date, after which the assignment is automatically revoked.
Every permission-related change is recorded in the audit log. This includes role creation, modification, deletion, permission changes, role assignments, and role revocations. Each audit entry captures the actor, the timestamp, the action performed, and the before/after state.
The audit log is immutable and accessible to workspace administrators. Use it to review access changes over time, investigate security incidents, or satisfy compliance requirements.
Use expiration dates on role assignments for temporary access - for example, granting a contractor the "Editor" role for the duration of a project. The system automatically cleans up expired assignments.