FlowX 5.0 introduces a comprehensive role-based access control system with predefined roles at organization, workspace, and project levels.
Overview of workspaces access rights
FlowX 5.0 provides a structured role hierarchy designed to support multi-tenant workspace architecture while maintaining security and governance. The system includes predefined roles that cannot be modified, ensuring consistent access patterns across all FlowX deployments.
Authentication and authorization architecture
FlowX 5.0 separates authentication and authorization into distinct systems:- Authentication (Keycloak)
Handles user identity and login
- User login and identity verification
- Token generation for authenticated users
- User creation and management in identity provider
- Service account identification with
SA_FLOWX
role
Designer vs Runtime Permissions
- Designer Permissions (New in 5.0): Control access to FlowX Designer interface, managed through workspaces and the new role system
- Runtime Permissions: Control process execution and data access, continue to be managed through Keycloak roles and remain unchanged from FlowX 4.x
Role architecture
Organization Level
Cross-workspace administrative access for managing the entire FlowX organization
Workspace Level
Workspace-specific roles for managing resources, users, and configurations within a workspace
Project Level
Project-specific roles for controlling access to individual projects and their resources
Organization level roles
Organization admin (org_admin
)
Organization Admin
Full administrative access across the entire FlowX organizationKey Characteristics:
- Cannot be edited, duplicated, or deleted
- Can only be assigned in the Organization admin interface
- Hidden from workspace role lists
- Highest level of access in the FlowX hierarchy
- Platform administrators
- IT managers responsible for FlowX deployment
- System architects managing multi-workspace environments
Organization admin default permissions
The following table shows the specific permissions assigned to the organization admin role:Legend: β
Permission assigned | β Permission not set | β¬ Permission not available to configure
Resource | Read | Edit | Create | Delete | Admin | Comments |
---|---|---|---|---|---|---|
Organization Administration | ||||||
Organization | β¬ | β | β¬ | β¬ | β¬ | Organization settings management |
Workspaces | β | β | β | β | β | Complete workspace lifecycle control |
Users | β | β | β | β | β¬ | Organization user management |
Groups | β | β | β | β | β¬ | User group management |
System Management | ||||||
Out of office | β | β | β | β | β¬ | Out of office policy management |
Fonts | β | β | β | β | β¬ | Global font resource management |
Monitoring & Audit | ||||||
Audit logs | β | β | β | β | β¬ | Read-only access to system audit |
Platform status | β | β | β | β | β¬ | System health monitoring |
Org Env Info | β | β | β | β | β¬ | Environment information management |
Org Audit log | β | β | β | β | β¬ | Organization-specific audit access |
The Organization Admin role should be assigned sparingly and only to users who need full cross-workspace administrative access. The organization admin has access to all the projects in all workspaces.
Workspace level roles
Workspace admin (workspace_admin
)
Workspace Admin
Complete control over workspace-level resources and usersKey Characteristics:
- Cannot be edited or deleted
- Can be assigned to users and groups within the workspace
- Listed in workspace role management interfaces
- Cannot manage organization-wide settings
- Business unit managers
- Workspace administrators
- Team leads with full workspace responsibility
Workspace admin default permissions
The following table shows the specific permissions assigned to the workspace admin role:Legend: β
Permission assigned | β Permission not set | β¬ Permission not available to configure
Resource | Read | Edit | Create | Delete | Admin | Comments |
---|---|---|---|---|---|---|
Workspace Management | ||||||
Workspace settings | β | β | β¬ | β¬ | β¬ | Configure workspace parameters and policies |
User & Group Management | ||||||
Users | β | β | β | β | β¬ | Add, remove, and manage workspace users |
Groups | β | β | β | β | β¬ | Create and manage user groups |
Projects & Libraries | ||||||
Projects | β | β | β | β | β¬ | Full project lifecycle management |
Libraries | β | β | β | β | β¬ | Complete library management control |
Dependencies | β | β | β | β | β¬ | Manage project and library dependencies |
Content & Branding | ||||||
Themes | β | β | β | β | β¬ | Theme creation and customization |
Fonts | β | β | β | β | β¬ | Font resource management |
Media assets | β | β | β | β | β¬ | Upload and organize media files |
Runtime & Configuration | ||||||
Runtime configurations | β | β | β | β | β¬ | Manage runtime settings and parameters |
Environment configs | β | β | β | β | β¬ | Configure deployment environments |
Integrations | β | β | β | β | β¬ | Set up external system connections |
Monitoring & Audit | ||||||
Workspace audit logs | β | β | β | β | β¬ | Read-only access to workspace audit |
Usage analytics | β | β | β | β | β¬ | View workspace usage statistics |
Performance metrics | β | β | β | β | β¬ | Monitor workspace performance |
Workspace user (workspace_user
)
Workspace User
Standard workspace access with project creation capabilitiesKey Characteristics:
- Cannot be edited or deleted
- Default role for most workspace members
- Limited administrative capabilities
- Business analysts and configurators
- Process designers and developers
- Team members who build projects within defined boundaries
- Users who need to create and manage their own work
Workspace user default permissions
The following table shows the specific permissions assigned to the workspace user role:Legend: β
Permission assigned | β Permission not set | β¬ Permission not available to configure
Resource | Read | Edit | Create | Delete | Admin | Comments |
---|---|---|---|---|---|---|
Workspace entities | ||||||
Projects & libraries | β | β¬ | β | β¬ | β | Can create new projects and libraries but cannot read all existing ones |
Fonts | β | β | β | β | β¬ | Read-only access to workspace fonts |
Global media library | β | β | β | β | β¬ | View workspace media assets |
Themes (includes fonts) | β | β | β | β | β¬ | Read-only access to workspace themes |
Global audit logs | β | β¬ | β¬ | β¬ | β¬ | Limited audit log visibility |
Workspace access management | ||||||
Workspace management | β | β | β¬ | β¬ | β¬ | WORKSPACE_READ permission required for basic workspace visibility |
Users | β | β | β | β | β¬ | View workspace users but cannot manage |
Groups | β | β | β | β | β¬ | View workspace groups but cannot manage |
[out of scope for 5.0] Out of office | β | β | β | β | β¬ | Out of office management not available in 5.0 |
Platform status | β | β¬ | β¬ | β¬ | β¬ | System status monitoring access |
Environment information | β | β¬ | β¬ | β¬ | β¬ | Environment configuration visibility |
Runtime permissions | ||||||
Builds | β | β¬ | β | β¬ | β¬ | View build information for accessible projects |
Active policy | β | β | β¬ | β¬ | β¬ | Read-only access to active policies |
Scheduled processes | β | β | β¬ | β | β¬ | View scheduled process information |
Configuration parameters overrides | β | β | β | β | β¬ | Read-only access to configuration parameters |
Process instances | β | β | β¬ | β¬ | β¬ | View process instances for accessible projects |
Task manager | β | β¬ | β¬ | β¬ | β¬ | Task management visibility |
Theme editor (theme_editor
)
Theme Editor
Specialized role for visual design and branding managementKey Characteristics:
- Same base permissions as workspace_user
- Additional permissions for visual asset management
- Focused on design and branding elements
- UI/UX designers
- Brand managers
- Visual design specialists
- Marketing team members managing brand assets
Theme editor default permissions
The following table shows the specific permissions assigned to the theme editor role:Legend: β
Permission assigned | β Permission not set | β¬ Permission not available to configure
Resource | Read | Edit | Create | Delete | Comments |
---|---|---|---|---|---|
Workspace entities | |||||
Projects & libraries | β | β¬ | β | β | Cannot create or manage projects/libraries - view only own work |
Fonts | β | β | β | β | Full font management capabilities |
Global media library | β | β | β | β | Complete media asset management |
Themes | β | β | β | β | Full theme creation and customization |
Global audit logs | β | β | β¬ | β¬ | Read-only audit log access |
Workspace Access management | |||||
Workspace management | β | β | β¬ | β¬ | WORKSPACE_READ permission required for basic workspace access |
Users | β | β | β | β | View workspace users but cannot manage |
Groups | β | β | β | β | View workspace groups but cannot manage |
Platform status | β | β¬ | β¬ | β¬ | System status monitoring access |
Environment information | β | β¬ | β¬ | β¬ | Environment configuration visibility |
Runtime permissions | |||||
Builds | β | β¬ | β | β¬ | View build information for accessible projects |
Active policy | β | β | β¬ | β¬ | Read-only access to active policies |
Scheduled processes | β | β | β¬ | β | View scheduled process information |
Configuration parameters overrides | β | β | β | β | Read-only access to configuration parameters |
Process instances | β | β | β¬ | β¬ | View process instances for accessible projects |
Task manager | β | β¬ | β¬ | β¬ | Task management visibility |
Workspace runtime editor (workspace_runtime_editor
)
Workspace Runtime Editor
Extended workspace user role with runtime configuration capabilitiesKey Characteristics:
- Same base permissions as workspace_user
- Additional permissions for runtime environment management
- Focused on runtime settings and configurations
- DevOps engineers
- Runtime environment administrators
- Technical team members managing deployment configurations
- System administrators with runtime responsibilities
Workspace runtime editor default permissions
The following table shows the specific permissions assigned to the workspace runtime editor role:Legend: β
Permission assigned | β Permission not set | β¬ Permission not available to configure
Resource | Read | Edit | Create | Delete | Admin | Comments |
---|---|---|---|---|---|---|
Workspace entities | ||||||
Projects & libraries | β | β¬ | β | β¬ | β | Can create new projects and libraries, but can read only those to which they have been granted access |
Fonts | β | β | β | β | β¬ | Read-only access to workspace fonts |
Global media library | β | β | β | β | β¬ | View workspace media assets |
Themes (includes fonts) | β | β | β | β | β¬ | Read-only access to workspace themes |
Global audit logs | β | β¬ | β¬ | β¬ | β¬ | Limited audit log visibility |
Workspace access management | ||||||
Workspace management | β | β | β¬ | β¬ | β¬ | WORKSPACE_READ permission required for basic workspace visibility |
Users | β | β | β | β | β¬ | View workspace users but cannot manage |
Groups | β | β | β | β | β¬ | View workspace groups but cannot manage |
Platform status | β | β¬ | β¬ | β¬ | β¬ | System status monitoring access |
Environment information | β | β¬ | β¬ | β¬ | β¬ | Environment configuration visibility |
Runtime permissions | ||||||
Builds | β | β¬ | β | β¬ | β¬ | Can create builds and view build information |
Active policy | β | β | β¬ | β¬ | β¬ | Can edit active policies and runtime configurations |
Scheduled processes | β | β | β¬ | β | β¬ | Full management of scheduled processes |
Configuration parameters overrides | β | β | β | β | β¬ | Complete control over configuration parameter overrides |
Process instances | β | β | β¬ | β¬ | β¬ | Can view and edit process instances |
Task manager | β | β¬ | β¬ | β¬ | β¬ | Task management visibility |
Project level roles
Project owner (project_owner
)
Project Owner
Complete ownership and governance of project resourcesKey Characteristics:
- Automatically assigned to project creator
- Cannot be edited, duplicated, deleted, or manually assigned
- Hidden from role selection interfaces
- System-managed role with highest project-level access
- Automatically granted when creating a project
- Cannot be transferred or reassigned through UI
- Permanent assignment for project lifecycle
Project owner default permissions
The following table shows the specific permissions assigned to the project owner role:Legend: β
Permission assigned | β Permission not set | β¬ Permission not available to configure
Resource | Read | Edit | Create | Delete | Admin/Owner | Comments |
---|---|---|---|---|---|---|
Projects & Libraries | β | β | β¬ | β | β | Complete project ownership and governance control |
Config permissions | ||||||
Processes | β | β | β | β | β¬ | Complete process definition and workflow management |
Enumerations | β | β | β | β | β¬ | Full enumeration management (also covers substitution tags functionality) |
Media library & Document Intelligence | β | β | β | β | β¬ | Complete media asset and document intelligence management |
Notification templates | β | β | β | β | β¬ | Full notification template configuration |
Document templates | β | β | β | β | β¬ | Complete document template management |
Views | β | β | β | β | β¬ | UI view configuration and management |
Stages | β | β | β | β | β¬ | Process stage definition and configuration |
Allocation rules | β | β | β | β | β¬ | Task and resource allocation rule management |
Systems | β | β | β | β | β¬ | External system integration configuration |
Workflow | β | β | β | β | β¬ | Workflow definition and management |
Reusable UI | β | β | β | β | β¬ | Complete UI component management with permission inheritance from project role |
Reusable Functions | β | β | β | β | β¬ | Full function component management with permission inheritance from project role |
Dependencies | β | β | β | β | β¬ | Project and library dependency management |
Configuration parameters | β | β | β | β | β¬ | Project configuration parameter management |
AI agents | β¬ | β | β¬ | β¬ | β¬ | AI agent configuration (read not available, edit only) |
Runtime permissions | ||||||
Builds | β | β¬ | β | β¬ | β¬ | Can create and view builds |
Active policy | β | β | β¬ | β¬ | β¬ | Runtime policy management |
Scheduled processes | β | β | β¬ | β | β¬ | Scheduled process management |
Configuration parameters overrides | β | β | β | β | β¬ | Runtime configuration parameter override management |
Process instances | β | β | β¬ | β¬ | β¬ | Process instance monitoring and management |
Task manager | β | β | β | β | β¬ | Complete task management capabilities |
Project editor (project_editor
)
Project Editor
Full project configuration and management capabilitiesKey Characteristics:
- Assignable to users and groups
- Comprehensive project access without ownership rights
- Standard role for project team members
- Senior developers and configurators
- Technical leads on project teams
- Business analysts with advanced permissions
- Team members with full project configuration needs
Project editor default permissions
The following table shows the specific permissions assigned to the project editor role:Legend: β
Permission assigned | β Permission not set | β¬ Permission not available to configure
Resource | Read | Edit | Create | Delete | Submit Version | Comments |
---|---|---|---|---|---|---|
Projects & Libraries | β | β | β¬ | β | β¬ | Full project management except creation (handled at workspace level) |
Config permissions | ||||||
Processes | β | β | β | β | β¬ | Complete process definition and workflow management |
Enumerations | β | β | β | β | β¬ | Full enumeration management (also covers substitution tags functionality) |
Media library & Document Intelligence | β | β | β | β | β¬ | Complete media asset and document intelligence management |
Notification templates | β | β | β | β | β¬ | Full notification template configuration |
Document templates | β | β | β | β | β¬ | Complete document template management |
Views | β | β | β | β | β¬ | UI view configuration and management |
Stages | β | β | β | β | β¬ | Process stage definition and configuration |
Allocation rules | β | β | β | β | β¬ | Task and resource allocation rule management |
Systems | β | β | β | β | β¬ | External system integration configuration |
Workflow | β | β | β | β | β¬ | Workflow definition and management |
Reusable UI | β | β | β | β | β¬ | Complete UI component management with permission inheritance from project role |
Reusable Functions | β | β | β | β | β¬ | Full function component management with permission inheritance from project role |
Dependencies | β | β | β | β | β¬ | Project and library dependency management |
Configuration parameters | β | β | β | β | β¬ | Project configuration parameter management |
AI agents | β¬ | β | β¬ | β¬ | β¬ | AI agent configuration (read not available, edit only) |
Runtime permissions | ||||||
Builds | β | β¬ | β | β¬ | β¬ | Can create and view builds |
Active policy | β | β | β¬ | β¬ | β¬ | Runtime policy management |
Scheduled processes | β | β | β¬ | β | β¬ | Scheduled process management |
Configuration parameters overrides | β | β | β | β | β¬ | Runtime configuration parameter override management |
Process instances | β | β | β¬ | β¬ | β¬ | Process instance monitoring and management |
Task manager | β | β | β | β | β¬ | Complete task management capabilities |
Project viewer (project_viewer
)
Project Viewer
Read-only access to project configuration and settingsKey Characteristics:
- Can be assigned when granting project access
- Safe role for stakeholders needing visibility
- No modification capabilities
- Suitable for audit and review purposes
- Business stakeholders and executives
- Quality assurance team members
- External consultants needing project visibility
- Audit and compliance personnel
- New team members during onboarding
Project viewer default permissions
The following table shows the specific permissions assigned to the project viewer role:Legend: β
Permission assigned | β Permission not set | β¬ Permission not available to configure
Resource | Read | Edit | Create | Delete | Comments |
---|---|---|---|---|---|
Projects & Libraries | β | β¬ | β¬ | β | Read-only access to project and library information |
Config permissions | |||||
Processes | β | β | β | β | View process definitions and workflows |
Project data model | β | β | β | β | Read-only access to project data structure |
Enumerations | β | β | β | β | View enumeration values and data structures |
Media library & Document Intelligence | β | β | β | β | View media assets and document intelligence configurations |
Notification templates | β | β | β | β | View notification template configurations |
Document templates | β | β | β | β | View document template configurations |
Views | β | β | β | β | View UI configuration definitions |
Stages | β | β | β | β | View process stage definitions |
Allocation rules | β | β | β | β | View task and resource allocation rules |
Systems | β | β | β | β | View system integrations and endpoints |
Workflow | β | β | β | β | View workflow definitions and configurations |
Reusable UI | β | β | β | β | Read-only UI component access with permission inheritance |
Reusable Functions | β | β | β | β | Read-only function component access with permission inheritance |
Dependencies | β | β | β | β | View project and library dependencies |
Configuration parameters | β | β | β | β | View project configuration parameters |
AI agents | β¬ | β | β¬ | β¬ | Limited AI agent visibility (read not available) |
Runtime permissions | |||||
Builds | β | β¬ | β | β¬ | View build information and status |
Active policy | β | β | β¬ | β¬ | View active runtime policies |
Scheduled processes | β | β | β¬ | β | View scheduled process information |
Configuration parameters overrides | β | β | β | β | View runtime configuration parameter overrides |
Process instances | β | β | β¬ | β¬ | View process instance information and status |
Task manager | β | β | β | β | View task management information |
Special project features
AI Agents / Command Center Access
AI Agents / Command Center Access
FlowX 5.0 Changes:
- AI Agents permission is now a project-level permission
- Command Center is only available on project or library pages
- No longer available as a global workspace feature
- Access controlled through project role assignments
Role management rules
Predefined role restrictions
Cannot Be Deleted
Cannot Be Deleted
All predefined roles are protected from deletion to ensure system consistency and security. This prevents accidental removal of critical access controls.
Cannot Be Fundamentally Modified
Cannot Be Fundamentally Modified
Core permission structures of predefined roles cannot be altered. This ensures consistent behavior across all FlowX deployments and prevents security vulnerabilities.
Assignment Restrictions
Assignment Restrictions
Role assignment follows specific rules:
- Organization roles: Only assignable in organization admin interface
- Workspace roles: Assignable within workspace boundaries
- Project roles: Can be assigned when granting project access
- Owner roles: System-assigned only, cannot be manually granted
Role visibility rules
- Organization Interface
- Workspace Interface
- Project Access Management
org_admin
: org_admin role needs to be assigned to at least one user; during environment setup, a user must be configured to have the org_admin role- Assignable to multiple organization users (from Designer Users page)
Special permission features
Read-only view behavior
Read-Only ModeUsers with read-only permissions (project_viewer role) will see a read-only view in the resource page. This ensures they can access information for audit and review purposes without the ability to make changes.
- All configuration elements are visible but not editable
- Export and audit functionalities remain available
- Usage overview and resource tracking accessible
- Copy operations to other projects/libraries permitted
- Can test processes, workflows
This role allows user to test the project resources through the interface.
Administrative control
This inheritance model ensures:- Consistent access patterns across all project resources
- Simplified permission management with single point of control
- Predictable behavior for users across different resource types
- Reduced administrative overhead for access control
Default groups
FlowX groups
Workspace Access Management RequirementWhen managing access to projects/libraries, you need to set general access to all workspace users. The solution is to create and manage an
all_users_[workspace name]
group at workspace level to grant access efficiently.Everyone in workspace group
all_users_[workspace_name]
Automatically managed group for simplified access controlSystem Requirements:
- Created automatically when provisioning workspace
- Cannot be edited, deleted, or duplicated by users
- Automatically managed membership by the system
- Pre-selected when creating projects/libraries with role assignment options
- Returned in user/group search results for granting access to libraries/projects
- When a user is associated to a workspace (direct or through group), user is automatically added to this group
- When a user is removed from the workspace (direct or through group), user is automatically removed from this group
- Membership cannot be manually modified by administrators
- Pre-selected on access management screens when creating projects/libraries
- Available for role assignment to grant access to all workspace members
- Appears in search results when looking for users and groups to grant access
- Granting project access to all workspace members at once
- Applying workspace-wide policies and permissions
- Simplifying bulk access management operations
- Default group for shared workspace resources
Group naming convention
Group | UI Display Name | Technical Requirements |
---|---|---|
all_users_[workspace_name] | Everyone from <workspace name> | System-managed group representing all workspace members |
Additional group features
Group Membership Management
Group Membership Management
Automatic membership rules:
- Users are added to
all_users_[workspace_name]
when granted any workspace access - Users are removed when all workspace access is revoked
- Membership is maintained automatically by the system
- Cannot be manually modified by administrators
Access Management Workflows
Access Management Workflows
Using default groups effectively:
- Pre-selected when granting project access to simplify bulk operations
- Appears in user/group search results for easy selection
- Ideal for applying workspace-wide policies or shared resource access
- Reduces administrative overhead for common access patterns
Custom Groups
Custom Groups
Creating custom groups:
- Create groups for specific teams, departments, or functions
- Assign roles to groups for efficient permission management
- Use descriptive naming conventions (e.g.,
sales_team
,finance_analysts
) - Document group purposes and intended usage
Legacy role migration
FlowX 4.x to 5.0 role mapping
FlowX 4.x roles stored in Keycloak are not automatically migrated. Manual role assignment is required.
FlowX 4.x Role | FlowX 5.0 Equivalent | Notes |
---|---|---|
FLOWX_ADMIN | workspace_admin | Now workspace-scoped instead of global |
FLOWX_CONFIGURATOR | workspace_user or project_editor | Depends on required access level |
FLOWX_UI_DESIGNER | theme_editor | Enhanced with theme management capabilities |
FLOWX_VIEWER | project_viewer | Now project-specific instead of global |
Custom Keycloak roles | Manual review required | Assess against new role structure |
Migration considerations
Role Scope Changes
Roles are now workspace-scoped rather than global, requiring reassignment within workspace context
Granular Permissions
More fine-grained permission structure allows for better access control but requires role review
Database Storage
Roles are now stored in FlowX database instead of tokens, providing better performance and control
Hierarchy Changes
New role hierarchy requires review of user access patterns and organizational structure
Access control for import/export operations
Project and library import behavior
Import Type | Required Permission | Access Assignment |
---|---|---|
Project Version (first import) | project_create in workspace | Importing user becomes project_owner |
Project Version (existing) | project_create AND project_edit | Version added to existing project |
Project Build (first import) | project_build_create | Creates project, user becomes project_owner |
Project Build (existing) | project_build_create | Build added to existing project |
Library Version | Same as project version | Same ownership rules apply |
Library Build | project_build_create | Creates build only, no library config |
Cross-Workspace Import RestrictionsIf a project or library with the same configuration exists in another workspace on the same FlowX instance, the import will fail with an error message. Each project/library configuration can only exist in one workspace.
Library build sharing
Library builds can be shared across workspaces using the export/import mechanism, but libraries containing only builds will not be viewable to workspace users outside the Dependencies page.
Comprehensive permission matrices
The following permission matrices provide detailed access control information for all FlowX 5.0 roles. These matrices serve as the authoritative reference for understanding role capabilities and limitations.
Combined permission matrix (summary view)
The following provides a high-level overview of key permissions across roles:Organization-level permissions
Permission | org_admin |
---|---|
Workspaces | |
Create workspace | β |
Edit workspace settings | β |
Delete workspace | β |
View all workspaces | β |
Organization Users | |
Add users to organization | β |
Remove users from organization | β |
Assign organization roles | β |
View all user access | β |
Global Settings | |
Configure organization settings | β |
Manage global policies | β |
Access system configurations | β |
Workspace-level permissions
Permission | workspace_admin | workspace_user | theme_editor | runtime_editor |
---|---|---|---|---|
Projects | ||||
Create project | β | β | β | β |
View projects | β | β | β | β |
Delete any project | β | β | β | β |
Libraries | ||||
Create library | β | β | β | β |
View libraries | β | β | β | β |
Delete any library | β | β | β | β |
Themes & Branding | ||||
Create themes | β | β | β | β |
Edit themes | β | β | β | β |
Delete themes | β | β | β | β |
Manage fonts | β | β | β | β |
Runtime Management | ||||
Runtime configurations | β | β | β | β |
Runtime deployments | β | β | β | β |
User Management | ||||
Add workspace users | β | β | β | β |
Remove workspace users | β | β | β | β |
Assign workspace roles | β | β | β | β |
Create user groups | β | β | β | β |
Workspace Settings | ||||
Configure workspace | β | β | β | β |
Manage workspace policies | β | β | β | β |
View audit logs | β | β | β | β |
Project-level permissions
Permission | project_owner | project_editor | project_viewer |
---|---|---|---|
Process Design | |||
Create processes | β | β | β |
Edit processes | β | β | β |
Delete processes | β | β | β |
View processes | β | β | β |
Configuration | |||
Manage enumerations | β | β | β |
Configure templates | β | β | β |
Set up integrations | β | β | β |
Manage parameters | β | β | β |
Runtime Management | |||
Create builds | β | β | β |
Deploy to runtime | β | β | β |
Manage active policies | β | β | β |
View runtime status | β | β | β |
Access Control | |||
Grant project access | β | β | β |
Modify project permissions | β | β | β |
Remove project access | β | β | β |
Project Administration | |||
Delete project | β | β | β |
Archive project | β | β | β |
Export project | β | β | β |
Predefined FlowX roles
The following table provides comprehensive information about all predefined roles in FlowX 5.0:Role | Name | Description | Type | Key Characteristics |
---|---|---|---|---|
org_admin | Organization admin | Complete administrative access to manage users, workspaces, groups, roles, and system settings across the organization. | Organization | β’ Cannot be edited, duplicated, deleted β’ Only assignable in Organization admin space β’ Hidden from workspace role lists |
workspace_admin | Workspace admin | Manages workspace-level resources including users, roles, themes. Cannot manage organization-wide settings. | Workspace | β’ Cannot be edited, duplicated, deleted β’ Listed in workspace role lists β’ Can be assigned to users/groups |
workspace_user | Workspace user | Standard workspace access with project creation capabilities. Ideal for configurators building projects. | Workspace | β’ Cannot be edited, deleted β’ Can be duplicated for customization β’ Default role for workspace members |
theme_editor | Theme editor | Extended workspace user with theme, font, and media asset management capabilities. | Workspace | β’ Same base characteristics as workspace_user β’ Additional visual asset management permissions |
workspace_runtime_editor | Runtime editor | Extended workspace user with runtime configuration and deployment management capabilities. | Workspace | β’ Same base characteristics as workspace_user β’ Additional runtime management permissions |
project_owner | Project owner | Complete project ownership with governance rights. Automatically assigned to project creators. | Project | β’ System-managed role, cannot be edited/deleted β’ Hidden from role selection interfaces β’ Permanent assignment, cannot be transferred |
project_editor | Project editor | Full access to manage project resources, processes, workflows, and runtime settings. | Project | β’ Can be duplicated for customization β’ Standard role for project team members β’ Comprehensive access without ownership rights |
project_viewer | Project viewer | Read-only access to project configuration and runtime settings for audit and review purposes. | Project | β’ Safe role for stakeholders needing visibility β’ No modification capabilities β’ Suitable for compliance and monitoring |
Role permission summary
Organization Roles
org_admin - Complete administrative access across all workspaces, users, and system settings. See detailed permissions in the organization admin section above.
Workspace Roles
Available roles:
- workspace_admin - Full workspace management capabilities
- workspace_user - Standard user with project creation rights
- workspace_runtime_editor - Extended user with runtime configuration access
- theme_editor - Extended user with theme and branding management
Project Roles
Available roles:
- project_owner - Complete project ownership and governance
- project_editor - Full project configuration and management
- project_viewer - Read-only access to project settings and status
Best practices
Role assignment strategies
Principle of Least Privilege
Principle of Least Privilege
Always start with the minimum required access
- Begin with
project_viewer
for new users - Upgrade to
project_editor
only when needed - Reserve
workspace_admin
for actual administrators - Limit
org_admin
to platform administrators
Use Groups for Scale
Use Groups for Scale
Leverage groups for efficient management
- Create groups for teams, departments, or functions
- Assign roles to groups rather than individuals
- Use the default βEveryone in workspaceβ group for common access
- Document group purposes and membership criteria
Regular Access Reviews
Regular Access Reviews
Implement periodic access auditing
- Review role assignments quarterly
- Remove access for inactive users
- Validate that permissions match current responsibilities
- Document access decisions and approvals
Clear Role Documentation
Clear Role Documentation
Maintain role assignment documentation
- Document who has what roles and why
- Maintain approval records for sensitive role assignments
- Create role assignment procedures for your organization
- Train administrators on proper role management
Common role assignment patterns
- Small Team (5-15 users)
- Department (15-50 users)
- Enterprise (50+ users)
Simple structure for small organizations
- 1-2
workspace_admin
(team leads) - Most users as
workspace_user
- 1
theme_editor
(if visual customization needed) project_editor
assigned per project as needed
Current limitations in FlowX 5.0
The following features have specific limitations in FlowX 5.0:
- Custom roles not available (planned for future versions)
- Role transfer/ownership transfer not available (planned for 5.1)
- Bulk role assignment tools not available
- Workspace deletion functionality not available
- Moving projects/libraries between workspaces not supported
- Workspace-level audit logs for user management not implemented (planned for 5.1)
- Out of office management (planned for 5.1 at organization level)
- Runtime roles and groups will return errors if Keycloak is not the authentication provider
- Cache clearing required after lib2lib migration for proper functionality
- Inactive process instances require separate migration script if needed
Troubleshooting
Common role assignment issues
User Cannot Access Workspace
User Cannot Access Workspace
Possible Causes:
- User not assigned to workspace
- No role assigned in workspace
- User not in any workspace groups
- Verify user is in workspace user list
- Check role assignments
- Validate group memberships
- Review workspace permissions
Role Assignment Failed
Role Assignment Failed
Possible Causes:
- Insufficient permissions to assign role
- Role not available in current context
- System-managed role being manually assigned
- Verify assigner has
workspace_admin
role - Check role availability in current interface
- Confirm role can be manually assigned
- Review role assignment restrictions
Permissions Not Working
Permissions Not Working
Possible Causes:
- Role permissions not properly configured
- Cached permissions not updated
- Conflicting role assignments
- Clear user session and re-login
- Verify role permission matrix
- Check for multiple conflicting roles
- Review ACL overrides
Migration Access Issues
Migration Access Issues
Possible Causes:
- User not yet created in FlowX 5.0 system
- Legacy Keycloak roles still in use
- Initial organization admin not configured
- Ensure user has logged into FlowX Designer at least once
- Verify initial organization admin is configured
- Assign workspace access to migrated users
- Remove deprecated Keycloak Designer roles