Permission reference guide

Documentation Navigation:

Workspaces Access Rights - Role overview and concepts
Complete Permissions Matrix - Detailed permission specifications
Permission Reference Guide (Current) - Technical implementation details
Role Selection Guide - Practical scenarios and best practices

This guide provides technical reference information for FlowX Designer permissions, including naming conventions, UI element mappings, and implementation details. Use this guide when you need to understand how permissions work at a technical level.

Permission naming conventions

Naming structure

FlowX permissions follow a consistent naming pattern that helps identify scope and purpose:

[scope_prefix]_[resource]_[operation]

Scope prefixes

Prefix	Scope Level	Example Permissions	Usage
`org_`	Organization	`org_admin`	Cross-workspace administration and system-level operations
`wks_`	Workspace	`wks_users_read` • `wks_builds_create` • `wks_font_delete`	Workspace-level resources that apply across all projects in the workspace
`proj_`	Project	`proj_mediafile_read` • `proj_data_type_edit`	Project-specific resources when disambiguation from workspace resources is needed
(none)	Context-dependent	`process_read` • `workflow_edit` • `enum_create`	Project-level resources where context is clear from usage

Why some project permissions lack the proj_ prefix:Most project-level configuration resources (processes, workflows, enumerations, etc.) don’t use the proj_ prefix because:

Their context is always project-scoped
There’s no workspace-level equivalent that would create naming conflicts
Shorter names improve readability

The proj_ prefix is used when:

A workspace-level equivalent exists (e.g., proj_mediafile_* vs mediafile_* for workspace media)
Disambiguation is necessary (e.g., proj_data_type_* for project data model)

Operation suffixes

Suffix	Description	Typical Actions	Example Permissions
`_read`	View and access resource	• View lists • See details • Export data • Access audit logs	`process_read` • `wks_users_read` • `theme_read`
`_edit`	Modify existing resource	• Update properties • Change configurations • Save modifications	`workflow_edit` • `wks_active_policy_edit` • `enum_edit`
`_create`	Create new instances	• Add new items • Import data • Duplicate existing items	`project_create` • `wks_builds_create` • `notification_templates_create`
`_delete`	Remove resource	• Delete items • Remove from system	`stage_delete` • `wks_groups_delete` • `process_delete`
`_admin`	Administrative control	• Grant/revoke access • Manage permissions • Full governance	`projects_admin` • `org_admin`

Special naming cases

Properties named 'id' or 'url'

When a resource property is named “id” or “url” (case insensitive), it must be prefixed with userDefined: to avoid conflicts with system properties.Examples:

userDefined:URL - For a custom URL property
userDefined:id - For a custom ID field

This applies when working with:

Database properties
Configuration parameters
Custom data model fields

Date and place properties

Date Properties are split into multiple permission fields:

date:`{property_name}`:start
date:`{property_name}`:end (optional)
date:`{property_name}`:is_datetime (0 or 1)

Place Properties are split into multiple fields:

place:`{property_name}`:name
place:`{property_name}`:address
place:`{property_name}`:latitude
place:`{property_name}`:longitude
place:`{property_name}`:google_place_id (optional)

These expanded formats provide granular control over complex property types.

Checkbox property values

Checkbox properties use special string values instead of boolean:

__YES__ for checked
__NO__ for unchecked

Example:

{
  "Is Complete": "__YES__",
  "Requires Approval": "__NO__"
}

Number property format

Number properties must use JavaScript number format, not strings:Correct:

{"Priority": 5}

Incorrect:

{"Priority": "5"}

Substitution tags consolidation

Substitution tags use the enumeration permission set:

enum_read
enum_edit
enum_create
enum_delete

There are no separate substitution_tags_* permissions - enumeration permissions cover both resource types.

AI agent permissions

AI agent permissions deviate from the standard pattern:

Only aiagent_edit exists
No separate _read, _create, or _delete permissions
The edit permission grants access to all AI agent functionality (developer, analyst, designer)

Permission examples by category

Organization Level
Workspace Level
Project Level

Permission	Scope	Resource	Operation
`org_admin`	Organization	Administration	Admin (special)

Organization-level permissions are limited. Most administration occurs at workspace level.

Permission	Scope	Resource	Operation
`wks_users_read`	Workspace	Users	Read
`wks_users_create`	Workspace	Users	Create
`wks_groups_edit`	Workspace	Groups	Edit
`wks_roles_delete`	Workspace	Roles	Delete
`wks_builds_create`	Workspace	Builds	Create
`wks_active_policy_edit`	Workspace	Active Policy	Edit
`wks_config_param_overrides_read`	Workspace	Config Param Overrides	Read
`wks_process_instances_edit`	Workspace	Process Instances	Edit
`wks_process_instance_variables_edit`	Workspace	Process Variables	Edit
`wks_platform_status_read`	Workspace	Platform Status	Read
`wks_env_info_edit` ⚠️	Workspace	Environment Info ⚠️ Deprecated in 5.7.0; the Configure Environment Info UI has been removed.	Edit
`wks_audit_log_read`	Workspace	Audit Log	Read
`mediafile_create`	Workspace	Media Files	Create
`theme_edit`	Workspace	Themes	Edit
`wks_font_delete`	Workspace	Fonts	Delete
`proxy_connection_read`	Workspace	Proxy Connections	Read
`proxy_connection_edit`	Workspace	Proxy Connections	Edit
`proxy_connection_create`	Workspace	Proxy Connections	Create
`proxy_connection_delete`	Workspace	Proxy Connections	Delete

Permission	Scope	Resource	Operation
`project_read`	Project	Project/Library	Read
`project_owner`	Project	Project/Library	Owner (special)
`projects_admin`	Project	Projects	Admin
`process_edit`	Project	Processes	Edit
`proj_data_type_create`	Project	Data Model	Create
`enum_delete`	Project	Enumerations	Delete
`proj_mediafile_read`	Project	Media Library	Read
`notification_templates_create`	Project	Notification Templates	Create
`document_templates_edit`	Project	Document Templates	Edit
`task_view_read`	Project	Views	Read
`stage_create`	Project	Stages	Create
`allocation_rule_edit`	Project	Allocation Rules	Edit
`data_source_delete`	Project	Data Sources	Delete
`workflow_read`	Project	Workflows	Read
`reusable_ui_create`	Project	Reusable UI	Create
`reusable_br_edit`	Project	Reusable Business Rules	Edit
`dependency_read`	Project	Dependencies	Read
`config_param_create`	Project	Config Parameters	Create
`version_edit`	Project	Version Settings	Edit
`aiagent_edit`	Project	AI Agents	Edit (special)

Permission-to-UI action mapping

This section shows how permissions control specific UI elements and actions in FlowX Designer. When a user lacks a permission, the corresponding UI element is hidden or disabled.

Understanding UI behavior

Permission Enforcement Rules

Read Permission Behavior:

Read permission must be explicitly declared
Not automatically implied by other permissions
Exception: workspace_read is auto-included with any workspace permission

UI Display Rules:

Missing permission = Hidden UI element
Read-only permission = View mode with disabled controls
No error messages shown for hidden elements

Workspace level permissions

Themes
Fonts
Media Library
Users & Groups
Runtime Operations

Theme Permissions (`theme_*`)

Permission	UI Actions Enabled	UI Elements
`theme_read`	• View themes • Export theme	• Theme entry in main menu • Theme list in read-only mode • Export button
`theme_edit`	• Modify theme settings • Set as default • Configure theme sections • Copy from other themes	• Configure in contextual menu • Set as default button • Save button • All edit controls in theme sections • Copy from actions
`theme_create`	• Create new theme • Import theme • Duplicate existing theme	• Add button • Import action • Duplicate in contextual menu
`theme_delete`	• Remove theme	• Delete in contextual menu

When user has only theme_read, the theme page displays in read-only mode with all edit controls disabled.

Font Permissions (`wks_font_*`)

Permission	UI Actions Enabled	UI Elements
`wks_font_read`	• View font list • Export fonts	• Fonts entry in main menu • Font list in read-only mode • Export actions
`wks_font_create`	• Upload new fonts • Import font packages	• Add button • Import action
`wks_font_delete`	• Remove fonts	• Delete icon in contextual menu

Font editing is implicit with create permission - fonts are replaced rather than edited.

Media Library Permissions (`mediafile_*`)

Permission	UI Actions Enabled	UI Elements
`mediafile_read`	• View media assets • Export media files	• Global media library entry in main menu • Media list in read-only mode • Export button
`mediafile_edit`	• Update media metadata • Replace media files	• Edit controls for media properties
`mediafile_create`	• Upload new media • Import media packages	• Add button • Import action
`mediafile_delete`	• Remove media files	• Delete in contextual menu

User Management Permissions (`wks_users_*`)

Permission	UI Actions Enabled	UI Elements
`wks_users_read`	• View workspace users • See user details	• Users entry in main menu • User list in read-only mode
`wks_users_edit`	• Modify user workspace access • Update user roles	• Edit controls for user properties
`wks_users_create`	• Add users to workspace • Grant workspace access	• Add button • Grant access action
`wks_users_delete`	• Remove workspace access	• Delete in contextual menu

Group Management Permissions (`wks_groups_*`)

Permission	UI Actions Enabled	UI Elements
`wks_groups_read`	• View workspace groups • See group members	• Groups entry in main menu • Group list in read-only mode
`wks_groups_edit`	• Modify group membership • Update group properties	• Edit controls for groups • Add/remove member actions
`wks_groups_create`	• Create new groups	• Add button
`wks_groups_delete`	• Remove groups	• Delete in contextual menu

Role Management Permissions (`wks_roles_*`)

Permission	UI Actions Enabled	UI Elements
`wks_roles_read`	• View workspace roles • See role permissions	• Roles entry in main menu • Role list in read-only mode
`wks_roles_edit`	• Modify role permissions • Update role properties	• Edit controls for roles • Permission checkboxes
`wks_roles_create`	• Create custom roles • Duplicate existing roles	• Add button • Duplicate action
`wks_roles_delete`	• Remove custom roles	• Delete in contextual menu

Predefined roles (workspace_admin, workspace_user, etc.) cannot be edited or deleted regardless of permissions.

Build Permissions (`wks_builds_*`)

Permission	UI Actions Enabled	UI Elements
`wks_builds_read`	• View all workspace builds • See build details	• Runtime > Builds menu entry • Build list for all libraries
`wks_builds_create`	• Import build packages • Create builds from versions	• Import build button • Create build action on library versions

wks_builds_read allows viewing builds from all libraries in the workspace, not just accessible projects.

Active Policy Permissions (`wks_active_policy_*`)

Permission	UI Actions Enabled	UI Elements
`wks_active_policy_read`	• View active policies • See policy configurations • Access audit logs	• Active policy entry in Runtime tab • Policy page in read-only mode • Type and branch selectors disabled • Audit logs in contextual menu
`wks_active_policy_edit`	• Select branch/build • Update active policy • Change policy type	• Save button enabled • Branch/build dropdown selectors enabled • Policy type selector enabled

Configuration Parameter Overrides (`wks_config_param_overrides_*`)

Permission	UI Actions Enabled	UI Elements
`wks_config_param_overrides_read`	• View parameter overrides • See override values • Access audit logs	• Configuration parameters overrides menu entry • Override list in read-only mode • View icon on rows • Audit log in contextual menu
`wks_config_param_overrides_create`	• Add new overrides	• Add configuration parameter override button
`wks_config_param_overrides_edit`	• Modify override values	• Edit icon on table rows • Update override modal
`wks_config_param_overrides_delete`	• Remove overrides	• Delete in contextual menu

Process Variables (`wks_process_instance_variables_edit`)

Permission	UI Actions Enabled	UI Elements
`wks_process_instance_variables_edit`	• Edit process variables on active instances • Add/delete attributes/objects	• Edit option in contextual menu • Edit button in Variables tab • Monaco editor for JSON editing • Save button

This permission is assigned to the WORKSPACE_ADMIN and WORKSPACE_OPERATIONS_EDITOR roles.

Project level permissions

Project Management
Process Configuration
Content Management
Workflows

Project Permissions (`project_*`)

Permission	UI Actions Enabled	UI Elements
`project_read`	• View project details • Copy project UUID • Access audit logs	• Configure (shown as “View”) in contextual menu • Copy UUID action • Audit log access • Project details in read-only mode
`project_edit`	• Modify project settings • Configure project properties	• Configure in contextual menu • Edit controls enabled • Save button active
`project_create`	• Create new projects • Import project versions	• Add button • Import version action
`project_delete`	• Remove projects	• Delete in contextual menu

project_create is granted at workspace level. Users create projects within their workspace, not within other projects.

Process Permissions (`process_*`)

Permission	UI Actions Enabled	UI Elements
`process_read`	• View process list • Export processes • Copy to another project • Access audit logs	• Processes list • Export all button • Export in contextual menu • Copy to another project/library action • Audit logs access • Read-only process view
`process_edit`	• Modify process definitions • Configure process details • Edit process settings • Clear cache	• Configure details in contextual menu • Edit settings action • Save button • All edit controls on process designer • Clear cache action
`process_create`	• Create new processes • Import processes • Duplicate processes	• Add button • Import from ZIP (bulk) • Duplicate in contextual menu
`process_delete`	• Remove processes	• Delete in contextual menu

When user has only process_read, the process designer opens in read-only mode with all edit controls disabled.

Enumeration Permissions (`enum_*`)

Permission	UI Actions Enabled	UI Elements
`enum_read`	• View enumerations • Export enumerations • See enum values	• Enumerations entry in Project menu • Export to ZIP button • Export to CSV button • Read icon on enum rows • Read-only enum view
`enum_edit`	• Modify enum values • Configure enum settings • Add enum values • Create child enums • Remove enum values	• Edit icon on enum rows (replaces read icon) • Configure in contextual menu • Edit icon on enum value rows • Create child enum icon • Delete icon on enum value rows • Add value button
`enum_create`	• Create new enumerations • Import enumerations • Duplicate enumerations	• Add button • Import from ZIP • Import from CSV • Duplicate in contextual menu
`enum_delete`	• Remove enumerations	• Delete in contextual menu

The read icon automatically changes to an edit icon when the user has enum_edit permission.

Workflow Permissions (`workflow_*`)

Permission	UI Actions Enabled	UI Elements
`workflow_read`	• View workflows • Export workflows	• Workflows entry in Project menu • Export all (bulk) • Export in contextual menu
`workflow_edit`	• Modify workflow logic • Configure workflow settings • Edit workflow details • Clear cache • Delete condition nodes • Save code changes	• Configure in contextual menu • Edit details in resource page contextual menu • Clear cache in resource page contextual menu • Delete icon on Condition type nodes • Save changes in expanded code editor
`workflow_create`	• Create new workflows • Import workflows • Duplicate workflows	• Add button • Import from ZIP • Duplicate in contextual menu • Duplicate in resource page contextual menu
`workflow_delete`	• Remove workflows	• Delete in contextual menu

Permission dependency rules

Critical Permission Dependencies

Workspace Level:workspace_read - Automatically included when any other workspace permission is granted. Required for basic workspace visibility and validation.workspace_edit - Should be included when granting any workspace edit permission. Provides general workspace modification context.Project Level:project_read - Automatically sent to backend when any project-level permission is selected, even though not displayed in UI as selectable. Required for basic project access validation.Rule: Read permissions establish the foundation for all other permissions on a resource.

Groups technical reference

Understanding how groups work at a technical level helps administrators implement effective access control strategies.

System-managed groups

Everyone in workspace group

Technical Implementation

Display Name: Everyone in workspace (identical for every workspace; the workspace name is not embedded)Identifier: a system-generated UUID (there is no semantic all_users_* identifier)Automatic Behaviors:

Created during workspace provisioning by the authorization-system service
System-owned — cannot be manually modified via UI or API
Membership managed through workspace access events
Pre-populated in project access grant interfaces
Included in user/group search result sets

Use Cases:

Default access patterns for new projects
Workspace-wide policy application
Bulk access management operations
Simplified onboarding workflows

Custom group architecture

Group Structure
Permission Resolution
Performance Considerations

Group Properties:

Unique identifier (UUID)
Display name (user-defined)
Description (optional)
Workspace scope (cannot span workspaces)
Member list (user IDs)
Role assignments (workspace-level)

Group Membership:

Direct user assignments
No nested group support
Membership changes propagate immediately
Audit trail maintained for membership changes

When user has multiple group memberships:

Collect all permissions from all groups
Union permissions (more permissive wins)
Combine with individual user permissions
Apply most permissive result

Example:

User is member of:
- Group A: project_viewer on Project X
- Group B: project_editor on Project X

Result: User has project_editor access (more permissive)

Individual Override: Individual permission assignments take precedence over group-based assignments when more restrictive.

Advanced topics

Permission override scenarios

Multiple Role Assignments

Scenario: User assigned multiple roles at same levelResolution:

Permissions are combined (union)
Most permissive permission wins
Cannot have conflicting restrictions

Example:

User has both:
- theme_editor (theme permissions)
- workspace_runtime_editor (runtime permissions)

Result: User has both theme AND runtime permissions

Cross-Level Permission Conflicts

Scenario: Workspace role vs. project roleResolution:

Project-level permissions are additive to workspace permissions
Workspace role doesn’t auto-grant project access
Explicit project access required even with workspace admin role

Example:

User is workspace_admin:
- Has admin rights at workspace level
- Still needs project role to access specific projects
- Project owner can still restrict workspace admin

Group vs Individual Permissions

Scenario: User has both group-based and individual permissionsResolution:

Combine all permissions from all sources
More permissive permission wins
Individual cannot override to be more restrictive

Example:

Group A grants: project_viewer
Individual grant: project_editor

Result: User has project_editor (more permissive)

Permission caching and propagation

Caching Behavior

Cache Locations:

User session cache (browser)
Backend permission cache (per user)
Database role definitions (persistent)

Cache Invalidation:

User logout clears session cache
Role changes propagate within 5 minutes
Group membership changes immediate
Manual cache clear via re-login

Troubleshooting Cache Issues:

User logs out completely
Clear browser cache and cookies
User logs back in
Permissions refresh from database
If still not working, check role assignments

Workspaces Access Rights

Overview of FlowX workspace access rights and role hierarchy

Complete Permissions Matrix

Detailed permission matrices for all FlowX roles

Role Selection Guide

Practical guidance for choosing and assigning roles

Access Management Overview

Overview of FlowX access management system

​Permission naming conventions

​Naming structure

​Scope prefixes

​Operation suffixes

​Special naming cases

​Permission examples by category

​Permission-to-UI action mapping

​Understanding UI behavior

Permission Enforcement Rules

​Workspace level permissions

​Theme Permissions (theme_*)

​Font Permissions (wks_font_*)

​Media Library Permissions (mediafile_*)

​User Management Permissions (wks_users_*)

​Group Management Permissions (wks_groups_*)

​Role Management Permissions (wks_roles_*)

​Build Permissions (wks_builds_*)

​Active Policy Permissions (wks_active_policy_*)

​Configuration Parameter Overrides (wks_config_param_overrides_*)

​Process Variables (wks_process_instance_variables_edit)

​Project level permissions

​Project Permissions (project_*)

​Process Permissions (process_*)

​Enumeration Permissions (enum_*)

​Workflow Permissions (workflow_*)

​Permission dependency rules

Critical Permission Dependencies

​Groups technical reference

​System-managed groups

​Everyone in workspace group

Technical Implementation

​Custom group architecture

​Advanced topics

​Permission override scenarios

​Permission caching and propagation

Caching Behavior

​Related documentation

Workspaces Access Rights

Complete Permissions Matrix

Role Selection Guide

Access Management Overview

Permission naming conventions

Naming structure

Scope prefixes

Operation suffixes

Special naming cases

Permission examples by category

Permission-to-UI action mapping

Understanding UI behavior

Workspace level permissions

Theme Permissions (`theme_*`)

Font Permissions (`wks_font_*`)

Media Library Permissions (`mediafile_*`)

User Management Permissions (`wks_users_*`)

Group Management Permissions (`wks_groups_*`)

Role Management Permissions (`wks_roles_*`)

Build Permissions (`wks_builds_*`)

Active Policy Permissions (`wks_active_policy_*`)

Configuration Parameter Overrides (`wks_config_param_overrides_*`)

Process Variables (`wks_process_instance_variables_edit`)

Project level permissions

Project Permissions (`project_*`)

Process Permissions (`process_*`)

Enumeration Permissions (`enum_*`)

Workflow Permissions (`workflow_*`)

Permission dependency rules

Groups technical reference

System-managed groups

Everyone in workspace group

Custom group architecture

Advanced topics

Permission override scenarios

Permission caching and propagation

Related documentation