Scope: New access management and permission mechanism applies only to FlowX Designer access. Runtime permissions through Keycloak roles (at process level) remain unchanged.
Key benefits
Faster Onboarding
Onboard new business verticals in days instead of weeks with shared platform capabilities
Data Isolation
Provide secure separation between different business contexts while allowing controlled resource sharing
Enhanced Access Control
Implement granular permissions with role-based access control (RBAC) and access control lists (ACLs)
Key concepts
Workspace
A workspace is a logical grouping of entities and assets defined in FlowX that are only available to a subset of users who are given explicit access. Each workspace operates independently, ensuring data and configuration separation between different business contexts.Multi-workspace user access
Users can be granted access to multiple workspaces and can switch between them as needed. When a user has access to multiple workspaces, they can select which workspace to enter after authentication.Data isolation
Workspaces provide logical data isolation, meaning that resources (projects, libraries, themes, etc.) are scoped to specific workspaces and cannot be accessed from other workspaces without explicit sharing configurations.Additional terminology
- Group: A collection of users who share common characteristics, responsibilities, or access needs within a system. Groups are used to simplify access control by managing permissions collectively rather than assigning them individually to each user.
- Permissions: Define what actions can be performed on resources. They are fine-grained access controls that specify privileges for a resource type, such as: read process, edit process, delete process.
- Roles: Collections of permissions grouped together based on job functions or responsibilities. They simplify permission management by assigning a set of permissions to users instead of managing them individually.
Role assignment rule: Roles are never assigned directly to users or groups. A user or group is assigned a role ONLY when given access to a workspace OR a project/library. Exception:
org_admin role is the only one assigned to users directly at the organization level.When a user has multiple roles assigned in the context of a workspace or project, their access level is the union of all permissions from all roles associated with the user.
Workspace use cases
Multiple Business Lines
Multiple Business Lines
Isolation Level: HighDifferent use cases, projects, permissions, and users between business verticals (e.g., retail vs. corporate vs. investment banking).Shared Resources:
- Shared users across business lines
- Shared library builds
- Shared themes (configurable)
Regional Separation
Regional Separation
Isolation Level: MediumSame business line across different regions, subject to local regulations.Shared Resources:
- Libraries and common processes
- Some shared users with multi-region access
Distinct Organizations
Distinct Organizations
Isolation Level: HighestComplete separation for different customers or organizations.Shared Resources: NoneExample: A consulting firm providing FlowX services to multiple clients, with completely isolated workspaces for each client organization.
How workspaces work
Authentication and access flow
1
User Authentication
User logs in using OAuth 2.0 through the configured identity provider (Keycloak or client’s existing provider). Authenticated users are saved with subject ID in FlowX database.
2
Permission Retrieval
System fetches the user’s workspace permissions and available workspaces
3
Workspace Selection
If user has access to multiple workspaces, they select which workspace to enter
4
Context Loading
FlowX Designer loads with workspace-specific content, projects, and permissions
Workspace selection experience
The workspace selection experience varies based on user access:- Single Workspace Access
- Multiple Workspace Access
- No Workspace Access
Direct Navigation: Users with access to only one workspace are automatically redirected to the projects page within their workspace.UI Behavior: The workspace dropdown selector is disabled since no selection is needed.Session Flow: Simplified experience with no additional selection steps required.
Session management
Session Persistence: Workspace selection is saved for the user session. On subsequent visits within the same session, users are automatically redirected to their previously selected workspace.
Error handling and access denied scenarios
No Access to Selected Workspace
No Access to Selected Workspace
Trigger: User attempts to access a workspace they don’t have permissions for, or workspace ID is incorrectSystem Response: User is redirected to
workspace/403 error pageCommon Causes:- Workspace access was revoked
- User navigated to an invalid workspace ID
- Workspace was deleted or renamed
No Access to Resource
No Access to Resource
Trigger: User attempts to access a specific resource (project, library, etc.) they don’t have permissions forSystem Response: User is redirected to
403 error pageCommon Causes:- Insufficient project-level permissions
- Resource is restricted to specific roles or groups
- Project access was revoked
Resource management
- Project Isolation
- Library Sharing
- Theme Management
- Media Files & Fonts
Workspace Scoping: Each project is tagged with its workspace ID and only accessible within that workspaceIndependent Lifecycle: Projects in different workspaces can have the same names and follow independent versioningCross-Workspace Import: The same project can now be imported into multiple workspaces on the same environment. Each imported project maintains its own independent lifecycle with separate active policies and access controls.Import Behavior: Projects created from version or build import are created with access only for the currently logged in user with ‘Project Owner’ role. Workspace admins are also able to view projects. Access can be extended to required users subsequently.Runtime Permissions: Permissions for Runtime section are received by users with workspace role. Users inherit runtime permissions from workspace role for ALL projects/libraries they have access to.
Additional workspace features
Command Center (AI Agents)
AI Agents permission is a project level permission starting in FlowX 5.1 release. Consequence: Command center will be available only on projects or libraries pages.
Audit Logs
Audit log entry in main menu for every workspace will be available only for users with Workspace Admin role. The reason for this is that global audit log includes all logs for all projects/libraries in workspace.Access control
Role-based access control (RBAC)
For detailed role permissions and setup instructions, see Workspaces Access Rights.
Predefined Roles
- Project editor - Can modify project content, processes, and configurations. Includes all Project Viewer permissions.
- Project viewer - Read-only access to project content and processes. Cannot make modifications.
- Workspace user - View only access to workspace entities. Can create projects, but only sees projects they have explicit access to.
- Owner - Automatically assigned to project creators. Full control over project settings, access management, and can delete the project.
- Theme editor - Extends workspace user role to include permissions to manage themes and associated resources (global media files).
- Workspace admin - Manages all workspace level resources including users, roles, themes. Can configure access and content, but cannot manage organization-wide settings.
- Runtime editor - Enables users to test runtime functionality and manage runtime policies without full configurator permissions. Commonly used by QA teams and testers who need to manage “change active policy” operations and test processes during runtime without broader editing capabilities.
Workspace-Specific
Roles are specific to each workspace - a user can have different roles in different workspaces
In FlowX 5.1 release, only pre-defined roles will be available to use for workspace and project/library access.
Detailed role permissions
To add a user to a workspace, and to assign a role to the user, you need to go to Organization settings page and select your desired workspace, then add the user to the workspace and assign the role to the user.- Workspace admin: Manages all workspace level resources including users, roles, themes. Can configure access and content, but cannot manage organization-wide settings.
- Workspace user: View only access to workspace entities. Can create projects, but only sees projects they have explicit access to.
- Theme editor: Extends workspace user role to include permissions to manage themes and associated resources (global media files).
- Runtime editor: Enables users to test runtime functionality and manage runtime policies without full configurator permissions. Commonly used by QA teams and testers who need to manage “change active policy” operations and test processes during runtime without broader editing capabilities.
User groups
User groups simplify permission management by allowing you to assign permissions to groups rather than individual users.
- Default Groups: Each workspace includes an “Everyone in workspace” default group
- Custom Groups: Create groups based on teams, departments, or project requirements
- Inherited Permissions: Users automatically inherit permissions from their group memberships
Access control lists (ACLs)
Resource-Specific Permissions
Resource-Specific Permissions
Grant fine-grained control over individual resources within a workspace, allowing exceptions to general role permissions.Example: A user with
project_viewer role can be granted edit access to a specific project without becoming a full configurator.Exception-Based Access
Exception-Based Access
Provide specific users or groups access to individual resources without requiring full platform permissions.Use Case: External consultants can be given access to specific projects they’re working on without broader workspace access.
Owner Management
Owner Management
Resource creators can manage access to their specific resources without requiring full admin intervention.Benefit: Project owners can add team members to their projects without needing admin approval for each addition.
Project-level access control
Projects and libraries support fine-grained access control through dedicated project roles that work alongside workspace-level permissions.Project Owner
Automatically assigned to project creators. Full control over project settings, access management, and can delete the project.
Project Editor
Can modify project content, processes, and configurations. Includes all Project Viewer permissions.
Project Viewer
Read-only access to project content and processes. Cannot make modifications.
Creating a project
1
Create Project
Create a new project by clicking the + icon in the top-right corner of the Projects page.
2
Owner Assignment
The currently logged-in user is automatically assigned as Project Owner with full access rights.
3
Extend Access
Project owners can subsequently add users or groups with Project Editor or Project Viewer roles as needed.
Access management inheritance
- Project Editor role automatically includes Project Viewer permissions
- Multiple roles: Users can have both workspace-level and project-level roles simultaneously
- Permission union: When users have multiple roles, their access is the combination of all permissions from all assigned roles
Organization administration
Organization admin role
The
org_admin role is the only role assigned directly to users at the organization level, not workspace level.- Go to Organization Settings → Users.
- Find the user in the list and open their context menu (the three-dot menu).
- Select Set as ORG Admin.
Only an existing organization admin can promote another user. Use Set as ORG Admin directly — changing the role through the user’s Edit form is a different flow and is not how the organization admin role is assigned.
User management
The Organization Users page lists only Designer users — users who have logged into FlowX Designer at least once, or who were manually created by an organization admin. It does not list Runtime users (Keycloak roles/groups used for process-level permissions at runtime). Designer users and Runtime users are managed separately:- Designer users — managed in Organization Settings → Users. Control access to the FlowX Designer, workspaces, projects, and libraries.
- Runtime users — managed in Organization Settings → Runtime Roles and Runtime Groups. Control access to process instances at runtime (e.g., who can start or view a process).
User creation scenarios
- LDAP/Active Directory Users
- Direct FlowX Creation
Sync Behavior: Users from customer’s LDAP/Active Directory are not automatically created in FlowX.Onboarding Steps:
- User logs into FlowX Designer for the first time
- They are redirected to a “You’re not assigned to a workspace yet” message page
- User account is now created in FlowX and appears in the Users list in Organization Settings
- Organization admin assigns workspace access with appropriate role (Workspace User, Workspace Admin, Theme Editor, or Runtime Editor)
- On next login, user will have access to assigned workspaces
Users synced from LDAP will only appear in FlowX after their first login attempt.
Additional organization settings
Runtime roles and groups
Legacy Roles and Groups pages (for managing roles and groups only in Keycloak) are accessible in Organization Settings section and renamed Runtime Roles and Runtime Groups. Will be used going forward to manage any roles needed for process permission configuration.All workspaces will share the same list of runtime roles and groups.
Set environment info
Configuring client and environment information is available only in Organization settings section under Platform status page.Workspace management
Creating and managing workspaces
1
Admin Access Required
Only users with organization administrator permissions can create new workspaces
2
Workspace Configuration
Set workspace name, description, and basic settings during creation
3
User Assignment
Add initial users and assign appropriate roles to get started
Workspace environment type
Workspaces can be labeled with an Environment Type to indicate their purpose within your deployment. This helps administrators and users quickly identify the context of each workspace. Available environment types:
To set the environment type, go to Organization Settings → select your workspace → set the Environment Type dropdown.
User management within workspaces
- Adding Users
- Role Assignment
- Access Matrix
- Direct Assignment: Add users directly to workspace with specific roles
- Group Membership: Add users to groups that inherit workspace permissions
- Multi-Workspace Access: Users can be members of multiple workspaces
Migration and compatibility
Initial setup requirements
Complete setup instructions are available in the Workspaces Setup Guide.
- To create the first user in FlowX Designer with organization admin role, an environment variable
SPRING_LIQUIBASE_PARAMETERS_DEFAULTORGADMINUSERNAMEneeds to be configured with the username of the user from Identity Store (Keycloak/ other Identity Store from where the users are used to login in FlowX.AI). - If request to Keycloak fails, the fallback is to use
SPRING_LIQUIBASE_PARAMETERS_DEFAULTORGADMINUSERSUBJECTIDto create the organization admin user. Value that must be set is the subject identifier. (sub in JWT token OR user’s id in Keycloak).
This step is important for creating any environment, no matter if there’s a pre-existing env or a newly created one.
For existing FlowX customers
For existing FlowX customers
What Happens During Migration:Post-migration manual steps:
- All existing projects, libraries, and themes are moved to a default workspace
- All existing functionality continues to work without changes
- Name: “Default workspace” (can be changed following the migration)
- UUID: “00000000-0000-0000-0000-000000000001”
- All active process instances will be migrated under default workspace
- Failed process start instances migration
- Workflow instances migration
- Scheduled processes migration
- Audit logs migration
Out of office and Fonts will not be migrated under default workspace, as they are managed at organization level.
- Organization admin will need to provide individual access to workspace for each user
- Access to projects and libraries should be additionally configured as per workspace requirements
- Existing admin roles and groups used for FlowX Designer access are deprecated and should be removed post-migration from Keycloak
Step is optional, but encouraged so that the role list for runtime permissions is manageable. List of deprecated roles (which can be removed) will be provided in documentation.
For new FlowX 5.x installations
For new FlowX 5.x installations
Initial Setup Process:
- Configure the first workspace administrator user
- Create the initial workspace
- Set up users and role assignments
- Begin creating projects and processes
Best practices
Workspace design
Clear Boundaries
Define workspaces based on clear business, regulatory, or organizational boundaries
Naming Conventions
Use consistent naming conventions for workspaces, roles, and resources
Documentation
Document workspace purposes, user access patterns, and governance policies
Scalability Planning
Plan workspace structure to accommodate future growth and organizational changes
Permission management
- Principle of Least Privilege: Grant minimum necessary permissions
- Group-Based Management: Use groups for permission management rather than individual assignments
- Regular Audits: Periodically review and audit workspace permissions
- Clear Ownership: Establish clear ownership models for workspace resources
Resource sharing
- Controlled Sharing: Implement clear policies for resource sharing between workspaces
- Dependency Management: Track and manage dependencies between shared resources
- Version Control: Maintain version control for shared libraries and themes
Common use cases
Banking - Multi-Division Operations
Banking - Multi-Division Operations
Scenario: Large bank with retail, corporate, and investment banking divisionsWorkspace Structure:
- Retail Banking Workspace
- Corporate Banking Workspace
- Investment Banking Workspace
- Shared Compliance Workspace (for common libraries)
Insurance - Geographic Separation
Insurance - Geographic Separation
Scenario: Insurance company operating in multiple countriesWorkspace Structure:
- US Operations Workspace
- EU Operations Workspace
- APAC Operations Workspace
Cross-workspace project import
You can import the same project into multiple workspaces on the same environment. This feature enables organizations to use workspaces to represent different operational environments (such as UAT, staging, pre-production) on a single FlowX deployment, reducing operational costs.How it works
Import to Multiple Workspaces
Import a project build (and optionally a version) into different workspaces on the same environment
Independent Lifecycle
Each imported project maintains its own lifecycle with separate active policies and access controls
No Impact on Original
Importing to another workspace does not affect the original project’s settings, policies, or process instances
Separate Process Instances
Process instances are workspace-specific; imported projects have no instances initially until processes run in the new workspace
Import behavior
Limitations and considerations
Current limitations
- Resource Isolation: Direct access to resources from other workspaces is not possible
- Single Environment Sharing: Library sharing only works within the same FlowX environment
- Permission Inheritance: Workspace permissions don’t automatically inherit across workspace boundaries
FlowX 5.1 specific limitations
Planning considerations
- Change Management: Organizational alignment needed for governance models
- User Training: Users need to understand workspace selection and navigation
- Governance Policies: Clear policies needed for resource sharing and access management
- Migration Planning: Existing customers should plan workspace structure before creating additional workspaces