Documentation Navigation:
- Workspaces Access Rights - Role overview and concepts
- Complete Permissions Matrix (Current) - Detailed permission specifications
- Permission Reference Guide - Technical implementation details
- Role Selection Guide - Practical scenarios and best practices
This page provides comprehensive permission matrices for all predefined roles in FlowX. Use this as a reference when planning access control strategies.
How to use this reference
1
Identify the role level
Determine whether you need organization, workspace, or project-level access
2
Find the appropriate role
Review the role descriptions and select the one matching your requirements
3
Verify permissions
Check the detailed permission matrix to ensure it meets your needs
4
Implement access control
Assign roles according to the principle of least privilege
Permission legend
The permission matrices use the following symbols:Organization level permissions
Organization admin permission matrix
Theorg_admin role has the following permissions:
- Organization Administration
- System Management
- Monitoring & Audit
- End-user Management
Organization Admin Role Constraints
Management Rules:
- Cannot be edited, duplicated, or deleted
- Can only be assigned in the Organization admin space
- Hidden from workspace role lists
- Cannot be assigned at workspace level
- Must be assigned to at least one user during initial setup
Organization owner permission matrix
TheOrganization Owner is a predefined organization-level role focused on account, dashboard, usage, and end-user (runtime) administration. It is not interchangeable with Organization Admin: managing Designer users, workspaces, and Designer roles, including promoting another user to organization admin, requires the Organization Admin role.
Organization Owner Role Constraints
Management Rules:
- Predefined organization-level role
- Focused on account and end-user administration, not Designer platform administration
- For Designer user, workspace, and role management, use the Organization Admin role
Workspace level permissions
Workspace admin permission matrix
Theworkspace_admin role has the following permissions:
- Workspace Entities
- Runtime Entities
- Access Management
Workspace Admin Role Constraints
Management Rules:
- Cannot be edited or deleted (predefined role)
- Listed in workspace role management interfaces
- Can be assigned to users/groups within the workspace
- Can be assigned when granting access to workspace
- Cannot manage organization-wide settings
Workspace user permission matrix
Theworkspace_user role has the following permissions:
- Workspace Entities
- Runtime Entities
- Access Management
Workspace User Role Constraints
Management Rules:
- Cannot be edited or deleted (predefined role)
- Can be duplicated to create custom variations (future feature)
- Default role for most workspace members
- Can be assigned when granting access to workspace
- Limited administrative capabilities
Theme editor permission matrix
Thetheme_editor role extends workspace_user with additional permissions:
- Additional Permissions
- Inherited from workspace_user
Theme Editor Role Constraints
Management Rules:
- Same base constraints as
workspace_user - Cannot be edited or deleted (predefined role)
- Can be duplicated to create custom variations (future feature)
- Specialized role for UI/UX designers and brand managers
Workspace runtime editor permission matrix
Theworkspace_runtime_editor role extends workspace_user with additional permissions:
- Additional Runtime Permissions
- Inherited from workspace_user
Runtime Editor Role Constraints
Management Rules:
- Same base constraints as
workspace_user - Cannot be edited or deleted (predefined role)
- Can be duplicated to create custom variations (future feature)
- Specialized role for DevOps and runtime environment administrators
Workspace operations editor permission matrix
Theworkspace_operations_editor role extends workspace_user with additional permissions:
- Additional Operations Permissions
- Inherited from workspace_user
Operations Editor Role Constraints
Management Rules:
- Same base constraints as
workspace_user - Cannot be edited or deleted (predefined role)
- Can be duplicated to create custom variations (future feature)
- Specialized role for operations management (process migration & token operations)
Project level permissions
Project owner permission matrix
Theproject_owner role has the following permissions:
- Project Administration
- Configuration Resources
Project Owner Role Constraints
Management Rules:
- System-managed role, cannot be edited or deleted
- Automatically assigned to user who creates project
- Hidden from role selection interfaces
- Cannot be manually assigned through UI
- Permanent assignment for project lifecycle
- Can be transferred to another user (ownership transfer)
Project editor permission matrix
Theproject_editor role has the following permissions:
- Project Management
- Configuration Resources
Project Editor Role Constraints
Management Rules:
- Cannot be edited or deleted (predefined role)
- Can be duplicated to create custom variations (future feature)
- Can be assigned to users/groups when granting project access
- Standard role for project team members
- No ownership rights (cannot grant/revoke project access)
Project viewer permission matrix
Theproject_viewer role has the following permissions:
- Project Access
- Configuration Resources
Project Viewer Role Constraints
Management Rules:
- Cannot be edited or deleted (predefined role)
- Can be duplicated to create custom variations (future feature)
- Can be assigned to users/groups when granting project access
- Safe role for stakeholders needing visibility
- No modification capabilities
- Can test processes and workflows through the interface
Role comparison matrix
Quick reference: All roles compared
* Workspace-level roles can only edit project resources for projects they have been explicitly granted access to. Having a workspace role does not automatically grant access to all projects.
Detailed capability breakdown
Organization-level capabilities
Workspace-level capabilities
Project-level capabilities
Permission inheritance patterns
Workspace to project inheritance
Understanding how workspace roles interact with project roles is critical for proper access management.
-
Workspace roles DO NOT automatically grant project access
- A user with
workspace_adminstill needs explicit project role to access specific projects - Exception:
workspace_admincan grant themselves access via admin privileges - Exception: Users with
projects_adminpermission (included inworkspace_admin) automatically receiveproject_ownercapabilities on all projects in that workspace
- A user with
-
Project roles are additive to workspace permissions
- User can have
workspace_user+project_editoron specific project - Permissions combine (union), not override
- User can have
-
Most permissive permission wins
- If user has
project_viewervia one group andproject_editorvia another, they get editor access
- If user has
-
Multiple workspace roles can be assigned simultaneously
- Users can combine workspace roles for specialized access patterns
- Example: A user can be both
theme_editorandruntime_editorin the same workspace - Permissions from all assigned roles combine (union), enabling flexible role compositions
Group-based permission inheritance
Group Membership Resolution:- Userβs permissions = Union of (individual permissions + all group permissions)
- More permissive permission always wins
- No negative permissions (cannot restrict via groups)
Special permission features
Read-only view behavior
Read-Only Mode Characteristics
When a user has read-only permissions (e.g.,
project_viewer role), they experience:Visible but Disabled:- All configuration elements visible but not editable
- Save buttons hidden or disabled
- Edit controls grayed out or absent
- Delete actions not available
- Export operations (where applicable)
- Audit log access
- Usage overview and tracking
- Copy operations to other projects/libraries (for reference)
- Process and workflow testing through interface
- βViewβ label instead of βConfigureβ in contextual menus
- Read-only badges or indicators
- No modification prompts or warnings
Bulk permission selection
When configuring custom roles (future feature), bulk selection simplifies permission assignment.
How Bulk Selection Works:
- Select permission category (e.g., βWorkspace Entitiesβ)
- Choose operation level (e.g., βReadβ)
- All resources in category receive selected permission
- Individual permissions can be adjusted afterward
- Saves time when creating roles with consistent patterns
Permission dependencies
Auto-Included Permissions
Certain permissions automatically include others to ensure functionality:Workspace Level:
- Any workspace permission β automatically includes
workspace_read - Any workspace edit permission β should include
workspace_edit
- Any project permission β automatically includes
project_read(backend) - Note:
project_readnot displayed in UI but sent to backend
Related documentation
Workspaces Access Rights
Overview of FlowX workspace access rights and role hierarchy
Permission Reference Guide
Technical implementation details, UI mappings, and naming conventions
Role Selection Guide
Practical guidance for choosing and assigning appropriate roles
Access Management Overview
Overview of authentication and authorization in FlowX
Configuring IAM Solution
Setting up identity and access management with Keycloak
Workspaces
Understanding workspaces and organizing projects

