Workspaces access rights
Comprehensive guide to FlowX workspaces access rights
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_FLOWXrole
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
- 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
- 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
- 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
- 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
- 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
- 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
- All workspace_user permissions
- Create, edit, and delete themes
- Manage font resources and typography
- Upload and organize media assets
- Configure visual branding elements
- 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
- 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
- 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
- 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
- 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
- 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
- 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
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.
Duplication Rules
Duplication Rules
Some roles can be duplicated to create custom variations:
- Can duplicate:
workspace_user,theme_editor,project_editor,project_viewer - Cannot duplicate:
org_admin,workspace_admin,project_owner
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
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
- 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
- Granting project access to all workspace members
- Applying workspace-wide policies
- Simplifying bulk access management
- Default group for shared resources
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.
Permission matrix
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 |
|---|---|---|---|
| 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
| 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 | ✅ | ✅ | ❌ |
Best practices
Role assignment strategies
Principle of Least Privilege
Principle of Least Privilege
Always start with the minimum required access
- Begin with
project_viewerfor new users - Upgrade to
project_editoronly when needed - Reserve
workspace_adminfor actual administrators - Limit
org_adminto 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
Simple structure for small organizations
- 1-2
workspace_admin(team leads) - Most users as
workspace_user - 1
theme_editor(if visual customization needed) project_editorassigned 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 not available at workspace level (planned for 5.1)
- ❌ 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_adminrole - 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
Custom roles (planned for future)
Custom roles will be available in future FlowX versions, allowing organizations to create tailored access patterns.
- 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