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:
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
All roles and permissions described in this document apply only to FlowX Designer access.

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
Permissions:
  • Create, manage, and delete workspaces
  • Manage organization-wide users and access
  • Configure global roles and groups
  • Access all workspace resources across the organization
  • Manage system-wide settings and configurations
Use Cases:
  • Platform administrators
  • IT managers responsible for FlowX deployment
  • System architects managing multi-workspace environments
The Organization Admin role should be assigned sparingly and only to users who need full cross-workspace administrative access.

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
Permissions:
  • Manage workspace users, roles, and groups
  • Create, configure, and delete projects and libraries
  • Manage themes, fonts, and media assets
  • Configure workspace settings and policies
  • Grant and revoke access to workspace resources
  • View workspace-specific audit logs
Use Cases:
  • Business unit managers
  • Workspace administrators
  • Team leads with full workspace responsibility

Workspace user (workspace_user)

Workspace User

Standard workspace access with project creation capabilitiesKey Characteristics:
  • Cannot be edited or deleted
  • Can be duplicated to create custom variations
  • Default role for most workspace members
  • Limited administrative capabilities
Permissions:
  • Create and manage own projects
  • View and use existing libraries
  • Read-only access to themes and fonts
  • Basic workspace navigation and resource access
  • Cannot manage users, roles, or workspace settings
Use Cases:
  • 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

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
  • Can be duplicated for custom variations
  • Focused on design and branding elements
Permissions:
  • All workspace_user permissions
  • Create, edit, and delete themes
  • Manage font resources and typography
  • Upload and organize media assets
  • Configure visual branding elements
Use Cases:
  • UI/UX designers
  • Brand managers
  • Visual design specialists
  • Marketing team members managing brand assets

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
Permissions:
  • Full control over all project configuration
  • Manage project access and permissions
  • Configure runtime settings and deployments
  • Delete or archive the project
  • Grant access to other users and groups
  • Override project-level restrictions
Assignment:
  • Automatically granted when creating a project
  • Cannot be transferred or reassigned through UI
  • Permanent assignment for project lifecycle

Project editor (project_editor)

Project Editor

Full project configuration and management capabilitiesKey Characteristics:
  • Can be duplicated for custom variations
  • Assignable to users and groups
  • Comprehensive project access without ownership rights
  • Standard role for project team members
Permissions:
  • Create, edit, and delete processes and workflows
  • Manage enumerations and data structures
  • Configure notification and document templates
  • Set up system integrations and endpoints
  • Manage project configurations and parameters
  • Access runtime settings and build management
  • Configure project dependencies
Use Cases:
  • Senior developers and configurators
  • Technical leads on project teams
  • Business analysts with advanced permissions
  • Team members with full project configuration needs

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
Permissions:
  • View process definitions and workflows
  • Read enumeration values and data structures
  • View template configurations
  • See system integrations and endpoints
  • Read project settings and parameters
  • View runtime configurations and build status
Use Cases:
  • Business stakeholders and executives
  • Quality assurance team members
  • External consultants needing project visibility
  • Audit and compliance personnel
  • New team members during onboarding

Special project features

Role management rules

Predefined role restrictions

Role visibility rules

  • org_admin: Visible and assignable
  • Workspace roles: Not visible in organization interface
  • Project roles: Not visible in organization interface

Default groups

Everyone in workspace group

all_users_[workspace_name]

Automatically managed group for simplified access controlCharacteristics:
  • Created automatically when workspace is provisioned
  • Hidden from Groups management interface
  • Cannot be edited, deleted, or duplicated
  • System-managed membership
Behavior:
  • Users automatically added when granted workspace access
  • Users automatically removed when workspace access is revoked
  • Pre-selected when granting project or library access
  • Appears in user/group search for access management
Use Cases:
  • Granting project access to all workspace members
  • Applying workspace-wide policies
  • Simplifying bulk access management
  • Default group for shared resources

Additional group features

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 RoleFlowX 5.0 EquivalentNotes
FLOWX_ADMINworkspace_adminNow workspace-scoped instead of global
FLOWX_CONFIGURATORworkspace_user or project_editorDepends on required access level
FLOWX_UI_DESIGNERtheme_editorEnhanced with theme management capabilities
FLOWX_VIEWERproject_viewerNow project-specific instead of global
Custom Keycloak rolesManual review requiredAssess 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 TypeRequired PermissionAccess Assignment
Project Version (first import)project_create in workspaceImporting user becomes project_owner
Project Version (existing)project_create AND project_editVersion added to existing project
Project Build (first import)project_build_createCreates project, user becomes project_owner
Project Build (existing)project_build_createBuild added to existing project
Library VersionSame as project versionSame ownership rules apply
Library Buildproject_build_createCreates 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.

Permission matrix

Organization-level permissions

Permissionorg_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

Permissionworkspace_adminworkspace_usertheme_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
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

Permissionproject_ownerproject_editorproject_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

Best practices

Role assignment strategies

Common role assignment patterns

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:
Role Management:
  • ❌ 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 Features:
  • ❌ 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)
Integration Features:
  • ❌ Out of office management not available at workspace level (planned for 5.1)
  • ❌ Runtime roles and groups will return errors if Keycloak is not the authentication provider
Migration Features:
  • ⚠️ Cache clearing required after lib2lib migration for proper functionality
  • ⚠️ Inactive process instances require separate migration script if needed

Troubleshooting

Common role assignment issues

Custom roles (planned for future)

Custom roles will be available in future FlowX versions, allowing organizations to create tailored access patterns.
Planned Custom Role Features:
  • Workspace-level custom roles with configurable permissions
  • Project-level custom roles for specific access patterns
  • Role templates for common organizational patterns
  • Bulk role management and assignment tools
  • Advanced permission inheritance models