Skip to main content
Documentation Navigation:
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

PrefixScope LevelExample PermissionsUsage
org_Organizationorg_adminCross-workspace administration and system-level operations
wks_Workspacewks_users_read • wks_builds_create • wks_font_deleteWorkspace-level resources that apply across all projects in the workspace
proj_Projectproj_mediafile_read • proj_data_type_editProject-specific resources when disambiguation from workspace resources is needed
(none)Context-dependentprocess_read • workflow_edit • enum_createProject-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

SuffixDescriptionTypical ActionsExample Permissions
_readView and access resource• View lists • See details • Export data • Access audit logsprocess_read • wks_users_read • theme_read
_editModify existing resource• Update properties • Change configurations • Save modificationsworkflow_edit • wks_active_policy_edit • enum_edit
_createCreate new instances• Add new items • Import data • Duplicate existing itemsproject_create • wks_builds_create • notification_templates_create
_deleteRemove resource• Delete items • Remove from systemstage_delete • wks_groups_delete • process_delete
_adminAdministrative control• Grant/revoke access • Manage permissions • Full governanceprojects_admin • org_admin

​
Special naming cases

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 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 properties use special string values instead of boolean:
  • __YES__ for checked
  • __NO__ for unchecked
Example:
{
  "Is Complete": "__YES__",
  "Requires Approval": "__NO__"
}
Number properties must use JavaScript number format, not strings:Correct:
{"Priority": 5}
Incorrect:
{"Priority": "5"}
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 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
PermissionScopeResourceOperation
org_adminOrganizationAdministrationAdmin (special)
Organization-level permissions are limited in FlowX 5.0. Most administration occurs at workspace level.

​
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_*)

PermissionUI Actions EnabledUI 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.

​
Project level permissions

  • Project Management
  • Process Configuration
  • Content Management
  • Workflows

​
Project Permissions (project_*)

PermissionUI Actions EnabledUI 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.

​
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

Group Identifier: all_users_[workspace_name]Display Name: Everyone from <workspace name>Automatic Behaviors:
  • Created during workspace provisioning via database trigger
  • Membership managed through workspace access events
  • Cannot be manually modified via UI or API
  • Pre-populated in project access grant interfaces
  • Included in user/group search result sets
Database Relationships:
workspace (1) ←→ (1) all_users_group
user (N) ←→ (M) workspace_access
workspace_access → triggers → all_users_group_membership
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

​
Advanced topics

​
Permission override scenarios

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
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
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:
  1. User logs out completely
  2. Clear browser cache and cookies
  3. User logs back in
  4. Permissions refresh from database
  5. 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