ForjinnForjinn
User Management

Permissions Reference

Complete reference of permission keys in Forjinn's role-based access control (RBAC) system.

Permissions

Forjinn uses a fine-grained Role-Based Access Control (RBAC) system. Permissions are expressed as string keys that define specific actions a user can perform. Permissions are grouped into roles, and roles are assigned to users.

Permission Key Format

Permission keys follow a resource:action convention, where:

  • resource — the platform feature or area being controlled.
  • action — the specific operation allowed on that resource.

For example, chatflows:view allows a user to view chatflows, while chatflows:edit allows modifications.

Available Permission Keys

Chatflows

Permission KeyDescription
chatflows:viewView existing chatflows and their configurations
chatflows:createCreate new chatflows
chatflows:editModify existing chatflows
chatflows:deleteDelete chatflows
chatflows:deployDeploy or activate chatflows for production use
chatflows:executeRun and test chatflows

Agentflows

Permission KeyDescription
agentflows:viewView existing agentflows
agentflows:createCreate new agentflows
agentflows:editModify existing agentflows
agentflows:deleteDelete agentflows
agentflows:deployDeploy agentflows for production
agentflows:executeRun and test agentflows

Executions

Permission KeyDescription
executions:viewView execution history and logs for chatflows and agentflows
executions:deleteClear execution history

Credentials

Permission KeyDescription
credentials:viewView existing API credentials and keys
credentials:createAdd new credentials
credentials:editModify existing credentials
credentials:deleteRemove credentials

Tools

Permission KeyDescription
tools:viewBrowse available tools and integrations
tools:createAdd custom tools
tools:editModify existing tools
tools:deleteRemove tools
tools:useUse tools within chatflows and agentflows

Variables

Permission KeyDescription
variables:viewView environment and workflow variables
variables:createAdd new variables
variables:editModify existing variables
variables:deleteRemove variables

Assistants

Permission KeyDescription
assistants:viewView configured assistants
assistants:createCreate new assistants
assistants:editModify existing assistants
assistants:deleteDelete assistants

Knowledge Base

Permission KeyDescription
knowledgebase:viewView documents and datasets in the knowledge base
knowledgebase:createUpload and add documents to the knowledge base
knowledgebase:editModify knowledge base entries
knowledgebase:deleteRemove knowledge base entries

Logs

Permission KeyDescription
logs:viewView system, execution, and audit logs

Users and Roles (Admin)

Permission KeyDescription
users:viewView platform user accounts
users:createInvite or create new user accounts
users:editModify user details and role assignments
users:deleteRemove user accounts
roles:viewView configured roles
roles:createCreate new roles
roles:editModify role definitions and permissions
roles:deleteRemove roles

Settings

Permission KeyDescription
settings:viewView platform and workspace settings
settings:editModify platform and workspace settings

Billing

Permission KeyDescription
billing:viewView billing information, invoices, and usage
billing:editModify billing settings and payment methods

How Permissions Are Evaluated

When a user performs an action, Forjinn checks whether any of the user's assigned roles include the required permission key. If at least one role grants the permission, the action is allowed. This means a user's effective permissions are the union of all permissions across their assigned roles.

Default Role Permissions

  • Admin: All permission keys, including users:*, roles:*, settings:edit, and billing:*.
  • Editor: chatflows:*, agentflows:*, tools:use, credentials:view, executions:view, logs:view, variables:view.
  • Viewer: chatflows:view, agentflows:view, executions:view, tools:view, logs:view, variables:view.

Best Practices

  • Principle of Least Privilege: Assign only the permission keys necessary for a user's responsibilities. Avoid broad wildcard patterns where specific keys can be used.
  • Use Roles as the Primary Mechanism: Define roles with precise permission sets and assign users to roles rather than managing permissions on a per-user basis.
  • Audit Periodically: Review role definitions and user assignments regularly to ensure permissions align with current team structure and responsibilities.
  • Document Custom Roles: Keep a record of how custom roles map to permission keys so that onboarding and access reviews are straightforward.

On this page