Value Proposition Statement
Enforce Workspace-based Cluster visibility to establish a clear execution boundary between teams. By associating clusters with workspaces and scoping cluster visibility to workspace membership, Camunda enables customers to safely organise teams within a single organisation — reducing accidental cross-team access, improving clarity, and laying the foundation for scalable governance across Hub, Web Modeler, and Console.
User Problem
Current State
- All clusters are visible in all workspaces today.
- There is no execution-level boundary between teams within an organisation:
- Any user can see all clusters
- Cluster ownership and responsibility are implicit, not expressed in-product
This makes it easy to:
- Deploy to the wrong environment
- Misunderstand which team owns which runtime
Organisational & Platform Gaps
- Workspaces define collaboration, but do not scope execution context.
- Clusters live at the organisation level, disconnected from team structures.
- Users must rely on:
- Naming conventions
- External documentation
- Console-only context
The product does not reflect how customers actually organise teams and environments.
Impact on SaaS Customers
Many SaaS customers want to clearly separate:
- Teams
- Environments
- Responsibilities
Today, they cannot express these boundaries within a single organisation because:
- Clusters are globally visible
- Workspaces do not scope execution context
As a workaround:
- Customers create multiple organisations to approximate team isolation
- This increases operational overhead and fragments visibility
From an execution perspective, there is no real team boundary in the product today.
Target State
- Clusters are explicitly associated with one or more workspaces.
- Cluster visibility is enforced based on workspace membership:
- Users see only clusters associated with the workspaces they belong to
- Clusters outside those workspaces are hidden
- Organisation admins and owners retain visibility into all clusters. The product clearly expresses:
- Team ownership
- Execution responsibility
- Intended deployment scope
Release Notes
What’s New
- Added the ability to associate clusters with workspaces
- Enforced workspace-based cluster visibility:
- Non-admin users see only clusters associated with their workspaces
- Organisation admins and owners see all clusters
- Updated Hub surfaces to reflect scoped cluster visibility
What Stayed the Same
No changes to:
- Cluster provisioning
- Runtime authorisation inside clusters
- Deployment APIs (beyond filtered visibility)
Enforcement applies to visibility, not runtime-level permissions.
User Stories
Enforced Execution Boundaries
- As a workspace member, I want to see only the clusters associated with my workspace, so that I cannot accidentally deploy to a cluster owned by another team.
- As an organisation admin, I want cluster visibility scoped to workspace membership, so that execution responsibility is clear and enforced by the product.
- As an organisation admin, I want to assign clusters to workspaces, so that I decide which clusters can be used by each workspace.
Admin Oversight
- As an organisation admin, I want visibility into all clusters across workspaces, so that I can manage environments and troubleshoot issues across teams.
Modelling to Runtime Alignment
- As a workspace member, I want my workspace to define which clusters are visible, so that modelling and deployment decisions align with team ownership.
- I only see the clusters designated for my workspace by the CoE, giving me focus and reducing the probability of errors.
- In the project view, I can only configure and deploy to clusters that are visible for the workspace.
Open question:
- What happens if a cluster is removed from a workspace after it has already been configured for a project?
Implementation Notes
Open question:
- We need to define how a user can request a cluster for their workspace (or assign one if they have the appropriate permissions).
- Otherwise, the value of workspace-based isolation is limited if workspaces do not have controlled access to deployment environments.