Capabilities for managing multiple business lines within a single FlowX instance
Workspaces enable organizations to manage multiple business contexts within one FlowX instance while maintaining logical data isolation.
Scope: New access management and permission mechanism applies only to FlowX Designer access. Runtime permissions through Keycloak roles (at process level) remain unchanged.
Workspaces allow organizations to manage multiple business lines, verticals, or countries within a single FlowX instance. This feature enables logical data isolation while maintaining the flexibility to share resources when needed.
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.
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.
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.
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.
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)
Example: A multinational bank with separate workspaces for Retail Banking, Corporate Banking, and Investment Banking, each with its own processes but sharing common user authentication and compliance libraries.
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
Example: An insurance company with workspaces for US, EU, and APAC operations, sharing global insurance processes but maintaining region-specific compliance and regulatory processes.
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.
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
Complete Separation: Projects cannot be exported from one workspace to another on the same environmentWorkspace 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 versioningCritical Constraint: Having the same project or library configuration in multiple workspaces on the same FlowX instance is NOT permittedImport 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.
AI Agents permission is a project level permission starting in FlowX 5.0 release. Consequence: Command center will be available only on projects or libraries pages.
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.
In FlowX 5.0 release, audit logs for Workspace management, User management at ORG level, Workspace groups are not implemented. Feature will be included in FlowX 5.1 release.
Entries will be able to be added by organization admins for all users in organization. At workspace level, Workspace Admin users can add/modify entries only for workspace users.
In FlowX 5.0 release, Out of office is not available. Feature will be included in FlowX 5.1 release.
Workspace admin: Manages all workspace level resources including users, roles, themes. Can configure access and content, but cannot manage organization-wide settings.
Workspace admins will be able to view and edit ALL projects and libraries in workspace, regardless of project/library access 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).
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
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
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.
The org_admin role is the only role assigned directly to users at the organization level, not workspace level.
Organization admins will be able to see all workspaces and have the same permissions as Workspace Admins inside each workspace. Multiple users can have this role assigned. Role can be assigned/revoked by other org admins.
Users are created in FlowX only after their first login in FlowX Designer.
Organization users page lists only users created in FlowX (after first login or manually created by organization admins). User details page shows Workspace access summary.
Feature works only if Keycloak is the authentication provider. Helpful for internal use, but rarely used by customers. Note: might not be available in FlowX 5.0. If there is a need to create users, they need to be created directly in Keycloak.
When user is created using the + icon, the user is saved in Keycloak and FlowX designer. After successfully adding user, organization admins can immediately assign user to workspaces.
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.
If Keycloak is not used as authentication provider, Runtime Roles and Runtime Groups pages will return errors in FlowX 5.0.
Critical Setup Step: Before starting any FlowX 5.0 environment, the initial organization admin must be configured.
To create the first user in FlowX Designer with organization admin role, an environment variable spring.liquibase.parameters.flowx.initial-org-admin needs to be configured with the unique identifier of the user from Identity Store (Keycloak/ other Identity Store from where the users are used to login in FlowX).
This step is important for creating any environment, no matter if there’s a pre-existing env or a newly created one.
IMPORTANT: Instruct devops to set this user id BEFORE system startup. Otherwise the authorization-service startup will fail. Ensure the correct value is set. The correct value is the subject id of the user, value that will be populated by the authorization service in the access token used for FlowX login.
When upgrading to FlowX 5.0, a default workspace is automatically created containing all your existing resources.
What Happens During Migration:
All existing projects, libraries, and themes are moved to a default workspace
Previous Keycloak roles need to be recreated as database-stored roles
All existing functionality continues to work without changes
Default workspace details:
Name: “Default workspace” (can be changed following the migration)
UUID: “00000000-0000-0000-0000-000000000001”
What gets migrated:
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.
For clients who need inactive process instances migrated, we’ll provide migration script which will be run post migration.
Post-migration manual steps:
Important: Existing users will not be migrated; they will need to log into FlowX so that their user is created.
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.
Move projects or libraries to another workspace feature is not available
Workspace import/export is out of scope; each FlowX environment will have a default workspace configured initially and workspaces are managed independently on each instance
Transfer project/library ownership feature will be delivered in FlowX 5.1 release