Skip to main content

​
Overview

Forest enables admins to create and manage custom roles with granular permission controls. The roles system allows organizations to define what actions users can perform within the platform. Only users with Admin permission level can create and manage roles. Roles are configured in the Roles tab within project settings, where permissions apply to all users assigned to that role.

​
Permission levels

Forest defines five user permission levels with increasing administrative capabilities:
CapabilityUserManagerEditorDeveloperAdmin
Data Management✓✓✓✓✓
Browse collections✓✓✓✓✓
View, create, update, delete records*✓✓✓✓✓
Execute actions*✓✓✓✓✓
Inbox Management✓✓✓✓
Manage inbox and notifications✓✓✓✓
UI Customization✓✓✓
Customize layouts and views✓✓✓
Configure collection displays✓✓✓
Create and edit Smart Views✓✓✓
Create workspaces✓✓✓
Create dashboards✓✓✓
Create workflows✓✓✓
Environment Management✓✓
Manage environments✓✓
Configure environment settings✓✓
Deploy between environments✓✓
Team & Role Management✓
Manage teams and users✓
Create and manage roles✓
Configure project settings✓
Access all administrative features✓
*Based on collection and action permissions configured for the role

​
Roles

Roles are configured in Project Settings → Roles. Each role defines granular permissions for collections and actions.

​
Collection permissions

Control what users can do with data in each collection:
PermissionDescription
Read (List)Access to table view data - allows users to see the list of records in a collection
Read (Details)Access to details and summary view data for individual records - allows users to open and view a specific record’s complete information
CreateRecord creation capability, including the ability to duplicate existing records
UpdateModify existing records
DeleteRemove records permanently
ExportExport data from the collection in various formats (CSV, JSON, etc.)

​
Action permissions

Control user ability to trigger and approve actions:
PermissionDescription
TriggerAllow users assigned to this role to trigger this action - the basic execution permission
Require ApprovalActions won’t execute without manual approval - creates an approval workflow where actions are queued and must be reviewed before execution
ApprovePermits role members to approve trigger requests submitted by other users - can review and authorize pending action requests
Self ApproveAllows users to approve their own action requests - bypasses the need for another user to review the action, useful for trusted users who need faster execution

​
Approval workflows

When “Require Approval” is enabled for an action:
  1. User triggers the action
  2. Action enters pending state in the approval queue
  3. Users with “Approve” permission review the request
  4. Action executes once approved (or is cancelled if rejected)
Approval lifecycle: a triggered action becomes Pending, then either Approved (and Executed) or Cancelled This workflow ensures sensitive operations (like refunds, data exports, or account deletions) go through proper review before execution. Learn more about action approval workflows →

​
Conditional permissions

Restrict permissions based on data conditions using filters. For example, operators might trigger refunds under $1,000 without approval, while higher amounts require authorization. Conditional permissions allow you to:
  • Set data-based filters on any permission
  • Create dynamic permission rules based on field values
  • Combine multiple conditions with AND/OR logic
  • Apply different permission levels based on record data
Example: Allow the “Support” role to trigger refunds only when amount < 1000, otherwise require approval.

​
Default permissions

Configure default permissions that are automatically applied when new collections or actions are created. This ensures consistent permission settings across your project without having to manually configure each new collection or action. Default permissions are configured in Project Settings → Roles and apply to:
  • New collections added to your datasources
  • New actions created in the back-end
  • New fields added to existing collections
This saves time and ensures security by establishing baseline permissions that new elements inherit automatically.