Governed Workspaces with Cluster Associations - E2E User Journeys

Scope

This document captures end-to-end user journeys cover the following Hub epics:

• Introduce Workspaces and Projects in Camunda Hub
• Governed Workspace Creation & Access
• Enforce Cluster Visibility via Workspace Association

Relevant Personas

Two person groups within the Organisational Landscape:

• CoE: CoE Lead, CoE Admin
• Delivery Team: Team Lead, Developer, Operations Engineer

---

How to Read This Document

The journeys below are organized by persona.

Each persona’s journey weaves through all three epics as a continuous narrative — from initial platform setup, through governed workspace creation, to scoped cluster usage. This reflects how each persona experiences the product over time.

Phase	Epic	What Happens
Foundation	Introduce Workspaces and Projects in Camunda Hub	Org structure is defined; Workspaces and Projects are introduced
Governance	Governed Workspace Creation & Access	Workspace creation is governed; access is controlled
Deployment Boundaries	Enforce Cluster Visibility via Workspace Association	Clusters are scoped to workspaces; deployment boundaries are enforced

---

User Journeys in Figma

• Governed Workspaces with Cluster Associations
• Catalog

---

CoE Lead

Coordinates the CoE team. Leads org governance and policy management. Leads onboarding of delivery teams.

Scenario 1: Establish Workspace Strategy for the Organisation

(Largely happens outside Camunda Hub)

Context: The organisation is adopting Camunda Hub. The CoE Lead must define how teams, workspaces, and clusters map to business domains before any delivery team starts working.

1. Assess Organisational Landscape — CoE Lead reviews the current state: how many teams exist, what domains they cover, and what clusters are provisioned. Identifies that the flat structure (everyone sees everything) does not scale.
2. Define Workspace Taxonomy — Designs a workspace structure that maps to business domains or delivery teams (e.g., “Payments Team”, “Onboarding Team”, “Shared Services”). Documents naming conventions and purpose for each workspace.
3. Define Governance Policies — Establishes rules for workspace creation:
   • Only Org Admins can create workspaces (no self-service sprawl).
   • Every workspace must have a designated Team Lead as Workspace Admin.
   • Workspace naming must follow the agreed taxonomy.
   • Clusters are assigned per workspace — no global visibility for non-admins.
4. Define Cluster Assignment Strategy — Maps which clusters (dev, staging, production) should be visible to which workspaces. Decides whether teams share clusters or get dedicated ones.
5. Brief a CoE Admin — Hands off the workspace plan, governance rules, and cluster assignment map to the CoE Admin for execution in Hub.
6. Onboard Team Leads — Communicates the new structure to Team Leads. Explains how to work with workspaces, what access they’ll get, and how clusters are scoped.

Scenario 2: Review and Evolve Workspace Structure

Context: New teams need workspaces, and some existing workspaces need restructuring.

1. Audit Existing Workspaces — Reviews the current workspace landscape in the Organisation view. Checks workspace utilisation, membership, and cluster assignments.
2. Identify Gaps — Notices that some teams are sharing a workspace but have diverging needs. A new business domain has no workspace yet.
3. Update Governance Policies — Adjusts naming conventions or cluster assignment rules as needed.
4. Coordinate Changes — Works with CoE Admin to split, merge, or create workspaces. Ensures cluster visibility and assignment is updated accordingly.

---

CoE Admin

Manages the organisation: teams, members, access, API clients, and integrations.

Scenario 1: Onboard New Delivery Team To Hub

Context: Following the CoE Lead’s workspace strategy, the CoE Admin configures the organisation in Hub.

1. Log Into Camunda Hub — CoE Admin opens Hub and navigates to the Organisation-level view.
2. Create workspace for new delivery team — Navigates to Workspaces. Creates new workspaces based on the approved taxonomy. Defines the following:
   • Sets workspace name and description.
   • Assigns a Team Lead the Workspace Admin role.
   • Optionally adds initial members with workspace roles (Editor, Commenter, Viewer).
   • Assigns clusters — selects which clusters the workspace can access. This allows the workspace to be fully operational from the start.
   • Confirms workspace creation.
3. Automatic notifications to workspace members — Workspace members are notified that they were added to the workspace.
4. Communicate readiness internally — (Optionally) Internally informs the CoE and Team Lead that the workspace is ready. Automatic notifications are also sent to workspace members by Camunda.

Update Cluster Associations After Creation

Cluster associations can be modified at any time from two entry points:

• Organisation → Clusters page (cluster-centric):
  • CoE Admin selects a cluster and updates which workspaces can see and deploy to it.
  • Best for bulk changes that affect multiple workspaces at once.
• Organisation → Workspaces page (workspace-centric):
  • CoE Admin opens a specific workspace’s management view and edits its cluster assignments directly.
  • Best for targeted adjustments to a single workspace.

In both cases, changes are saved and affected Team Leads are notified.

Scenario 2: Handle Workspace Creation Request

Context: A Team Lead requests a new workspace for a newly formed delivery team.

1. Receive workspace request notification — Hub notifies CoE Admin that a Team Lead has submitted a workspace creation request.
2. Review request details — Opens the request. Reviews:
   • Proposed workspace name and purpose.
   • Requested team members.
   • Required clusters (dev, staging, production).
   • Justification and business domain.
3. Validate against policies — Checks whether the request aligns with governance rules:
   • Does the name follow the taxonomy?
   • Is there a legitimate need for a separate workspace (vs. joining an existing one)?
   • Are cluster assignments reasonable?
4. Approve or Reject:
   • Approve: Workspace is created. During the creation flow, CoE Admin assigns clusters to the workspace. Optionally adjusts initial membership. Team Lead is notified.
   • Reject: Provides feedback explaining why. Team Lead is notified.
5. Refine cluster assignments (if needed) — After creation, CoE Admin can manage cluster associations from the Organisation → Clusters page (cluster-centric) or the Organisation → Workspaces management page (workspace-centric) — e.g., to add a cluster that was provisioned later, or to adjust visibility.

Scenario 3: Manage Clusters and Cluster Assignments to Workspaces

Context: CoE Admin is on the organisation view and needs to manage clusters — updating, adding, deleting, or adjusting which workspaces they are assigned to.

Via Organisation → Clusters

1. Navigate to Clusters — CoE Admin opens the Clusters page and reviews the list of available clusters.
2. Update cluster to newer version — If a cluster needs to be updated to a new version:
   • Opens the cluster and performs the version update.
   • Reviews the updated cluster.
   • Reviews workspaces currently assigned to the cluster.
   • Updates assignments as needed (adds or removes workspaces).
   • Workspace members with Workspace Admin and Editor roles are notified about the assignment change. Commenters and Viewers are not notified.
3. Add a new cluster — If a new cluster needs to be provisioned:
   • SaaS: Creates the cluster in the Hub.
   • Self-Managed: Goes through the internal provisioning process, then registers the cluster in the Hub.
   • After creation or registration, reviews the cluster and assigns it to the relevant workspaces.
   • Workspace members (Workspace Admin and Editor roles) are notified when the cluster is added to their workspace.
4. Delete a cluster — If a cluster needs to be removed:
   • Initiates deletion from the Hub.
   • The system informs CoE Admin about any workspaces currently associated with the cluster.
   • CoE Admin confirms the deletion.
   • Workspace members (Workspace Admin and Editor roles) are notified about the cluster deletion from their workspace.
   • CoE Admin reviews whether any assignments between the deleted cluster and workspaces need to be resolved (e.g. assigns other clusters to workspaces).

Via Organisation → Workspaces

1. Navigate to Workspaces — CoE Admin navigates to the Workspaces page and reviews the workspace list.
2. Navigate to workspace clusters — Identifies a workspaces that needs to be updated. Opens a workspace management view and goes to its clusters.
3. Updates cluster assignments — Adds or removes clusters assigned to that workspace.
4. Automatic notifications to workspace members — Workspace members (with Workspace Admin and Editor roles) are notified about the change. Users with Commenter and Viewer roles are not notified.

Scenario 4: Onboard New Organisation Member to Workspace

Context: A new employee joins the organisation and needs access to specific workspaces. The CoE Admin onboards the user from the Organisation level.

Camunda Hub supports OIDC integration with the organisation’s external Identity Provider (e.g., Entra ID, Keycloak, Okta) and user accounts are managed in the IdP rather than in Hub. On SaaS, a built-in identity (Auth0) with direct invitations is supported as well.

Invite Member to the Organisation (if needed)

The way a new employee gains access to the organisation depends on the deployment model:

• Self-Managed: The employee is registered in the organisation’s Identity Provider. Once registered, the user can authenticate to Camunda Hub via OIDC.
• SaaS Enterprise (integrated with IdP): The employee is registered in the organisation’s Identity Provider. Once registered, the user can authenticate to Camunda Hub via OIDC.
• SaaS (built-in Auth0): CoE Admin invites the new employee to the organisation in Hub and assigns an organisation role.

Assign to Workspace(s)

1. Navigate to organisation workspace management — CoE Admin opens Hub and goes to the organisation-level workspace management.
2. Check if the employee is already an org member:
   • If yes — Add the org member (new employee) to workspace(s) and assign workspace role.
   • If no — Invite the new employee via email to workspace(s) and assign workspace role. The invited user will get basic org-level access to Hub when the invite is accepted.
3. New workspace member is notified — The new employee receives a notification that they were added to (or invited to) the workspace.
4. User has scoped access — The new workspace member sees only the workspaces they are added to.

Scenario 5: Onboard New Team Lead to Hub

Context: A team lead of a new team needs to get access to Hub to onboard their team and build process solutions. The CoE Admin onboards the Team Lead from the Organisation level. There are two onboarding paths depending on the level of autonomy the Team Lead should have.

Option A: Add Team Lead as Workspace Admin to a Specific Workspace

The CoE Admin assigns the Team Lead to a pre-created workspace. The Team Lead has basic org-level access and can manage only the workspace(s) they are added to.

1. Ensure the Team Lead has access to the organisation:
   • Self-Managed: The Team Lead is registered in the organisation’s Identity Provider.
   • SaaS Enterprise (integrated with IdP): The Team Lead is registered in the organisation’s Identity Provider.
   • SaaS (built-in Auth0): CoE Admin invites the Team Lead to the organisation in Hub.
2. Navigate to organisation workspace management — CoE Admin opens Hub and goes to the organisation-level workspace management.
3. Add the Team Lead to the workspace — Adds or invites the Team Lead to the workspace and assigns the Workspace Admin role. The Team Lead gets basic org-level access to Hub.
4. Team Lead is notified — The Team Lead is notified that they were added to the workspace.
5. Team Lead has scoped access — The Team Lead can see and manage only the workspaces they are added to.

Option B: Add Team Lead as Workspace Manager to the Organisation

The CoE Admin gives the Team Lead the Workspace Manager organisation role. The Team Lead can create and manage their own workspaces without CoE Admin involvement.

1. Ensure the Team Lead has access to the organisation:
   • Self-Managed: The Team Lead is registered in the organisation’s Identity Provider.
   • SaaS Enterprise (integrated with IdP): The Team Lead is registered in the organisation’s Identity Provider.
   • SaaS (built-in Auth0): CoE Admin invites the Team Lead to the organisation in Hub.
2. Assign the Workspace Manager org role — Assigns the Team Lead the Workspace Manager organisation role.
3. Team Lead is notified — The Team Lead is notified that they were added to the organisation.
4. Team Lead can self-manage workspaces — With the granted Workspace Manager role, the Team Lead can create workspaces in the Hub organisation and manage the created workspaces. The Team Lead does not have permission to assign clusters to workspaces.

---

Team Lead

Technical lead of a Delivery Team. Manages team members, ensures technical enablement, decides on technical architecture.

Scenario 1: Invited to an Existing Workspace as Workspace Admin

Context: CoE Admin has created a workspace and added the Team Lead as Workspace Admin (see CoE Admin Scenario 5, Option A). The Team Lead receives a notification and takes over the workspace.

1. Receive workspace invitation notification — Team Lead is notified they have been added to a workspace as Workspace Admin.
2. Open workspace — Logs into Hub. The user is navigated to the Workspace they were added to.
3. Review workspace — Reviews the workspace and the initial setup. Checks:
   • Workspace name and description.
   • Current members and their roles.
   • Assigned clusters (visible clusters scoped by CoE Admin).
4. Adjust membership if needed — Adds or removes members, adjusts roles to reflect the actual team composition.
5. Create projects — Creates one or more projects within the workspace. Optionally organises files and folders within each project.
6. Assign projects to clusters — Configures each project’s deployment target from the available clusters. Only clusters visible to this workspace appear in the selection.
7. Kick off the development — Notifies the team that the workspace is ready. Developers can start working.

Scenario 2: Onboarded as Workspace Manager — Create and Set Up Workspace

Context: CoE Admin has added the Team Lead to the organisation with the Workspace Manager role (see CoE Admin Scenario 5, Option B). The Team Lead can now create and manage their own workspaces.

1. Receive notification — Team Lead is notified that they were added to the organisation with the Workspace Manager role.
2. Log into Hub — Opens Hub. Sees the organisation view. No workspaces are assigned yet.
3. Create a workspace — Creates a new workspace. Sets workspace name and description.
4. Add team members — Invites or adds team members to the workspace and assigns workspace roles (Editor, Commenter, Viewer).
5. Create projects — Creates one or more projects within the workspace.
6. Request cluster assignment — The Team Lead does not have permission to assign clusters to workspaces. Submits a request to CoE Admin to assign clusters to the workspace.
7. Clusters become available — Once the CoE Admin assigns clusters, the Team Lead configures deployment targets for projects.
8. Kick off the development — Notifies the team that the workspace is ready. Developers can start working.

Scenario 3: Request a New Workspace

Context: The Team Lead has access to Hub but needs a new workspace. The new workspace is needed for a new delivery team or business domain.

1. Log In to Hub:
   • If the user doesn’t have access to any workspace, they see an empty state: “You don’t have access to any workspaces yet.” The empty state provides guidance on what to do next.
   • If the user has access to workspaces, the latest used workspace opens.
2. Initiate workspace request:
   • Go to the organisation view and navigate to Workspaces.
   • Select “Request Workspace” and fill in the purpose / business domain it is needed for.
3. Submit for approval”
   • Request is sent to CoE Admin. Team Lead sees pending status and can track the request.
4. Outcome:
   • Approved — CoE Admin approves the request.
     • Workspace is created with assigned clusters and initial membership.
     • Team Lead is notified and assigned as Workspace Admin.
     • Team Lead proceeds to operate the workspace.
   • Rejected — CoE Admin rejects the request.

Scenario 4: Onboard New Employee to Workspace

Context: A new employee needs to be added to the Team Lead’s workspace. The Team Lead onboards them from the Workspace view.

1. Navigate to workspace — Team Lead opens their workspace.
2. Open workspace settings — Goes to the workspace settings / members view.
3. Check if the employee is already an org member:
   • If yes — Add the org member (new employee) to the workspace and assign workspace role (Editor, Commenter, or Viewer).
   • If no (SaaS with Auth0) — Invite the new employee via email to the workspace and assign workspace role.
4. New workspace member is notified — The new employee receives a notification that they were added to the workspace.
5. User has scoped access — The new workspace member sees only the workspace they were added to.

Scenario 5: Review Clusters and Request Additional Cluster Access

Context: The workspace is active. The Team Lead needs to review current cluster assignments and request access to an additional cluster.

1. Review cluster availability — Team Lead opens Workspace Settings and reviews which clusters are currently assigned to the workspace. Notices that the workspace does not have a cluster for a specific version or environment (e.g., production, or a newer Camunda version).
2. Request additional cluster access — Submits a request from cluster settings in the workspace to get access to a new cluster. Provides purpose for the request.
3. Track request status — The request triggers an approval flow to CoE Admin. Team Lead can track the request status in Hub.
4. Cluster becomes available — Once approved, CoE Admin assigns the cluster to the workspace. Team Lead and workspace members with Workspace Admin and Editor roles are notified.
5. Update deployment targets — Team Lead reviews projects and updates deployment configurations to use the newly available cluster.

---

Developer

Models processes, implements technical solutions, creates resources, tests and deploys processes.

Scenario 1: Join Workspace and Start Building

Context: The Developer has been added to a workspace by the Team Lead and begins their first project.

1. Receive notification about workspace access — Developer is notified that they’ve been added to a workspace with the Editor role.
2. Open Workspace — Logs into Hub. Sees only the workspace(s) they are a member of. Opens the workspace.
3. Workspace Overview — Sees:
   • List of projects in the workspace.
   • Team members and their roles.
   • Available clusters (only clusters that are assigned to the workspace).
4. Open project — Opens the project. Sees:
   • File hierarchy.
   • Connected Git repository (if any).
5. Build a process — Creates or edits a process within the project. Uses available Catalog assets when needed.
6. Test the process — Tests the implemented process solution on the Canvas and by using Camunda’s SDKs for testing.
7. Push project updates to Git — Pushes the updates to the connected Git repo.
8. Deploys the project:
   • For Non-Production, deploys the project to the scoped clusters via the Hub UI or API. Only clusters assigned to the workspace can be used as deployment target.
   • For Production, deploys via CI/CD pipeline according to the organisation policy.
9. Iterate — Continues development, deploying iteratively.

Scenario 2: Work Across Multiple Projects

Context: The Developer works on multiple projects within the same workspace.

1. Navigate to the workspace — Open a workspace. Get an overview of workspace projects.
2. Switch Between Projects — Navigates within different projects of the workspace when needed.
3. Consistent context — All projects share the same workspace members, roles, and cluster visibility.
4. Distinct Git connections — Each project has it’s own connection to Git repo.
5. Independent deployment — Each project can be deployed independently to the same or different clusters within the workspace scope.

Scenario 3: No Access to Workspace (New User)

Context: A newly onboarded developer logs in to Camunda Hub for the first time. They are an Organization Member but have not yet been assigned to any workspace.

1. Log In — After log in, the user is navigated to the organisation view, since they are not members of any workspace.
2. Scoped access to organisation view — On the organisation level the user has basic access according to the Member role.
3. Navigate to workspaces — On the workspaces page the user see an empty state communicating that they’re not members of any workspace.
4. Request new workspace — The user has an option to request a new workspace.
5. Review Catalog — The user can navigate to the Catalog and review available catalog assets.

---

Operations Engineer

Monitors process execution, resolves operational issues, reports on process performance.

Scenario 1: Monitor and Operate Within Scoped Clusters

Context: The Operations Engineer is a member of the “Payments Team” workspace and monitors process executions on the team’s clusters.

1. Access the workspace — Logs into Hub and opens the “Payments Team” workspace.
2. View assigned clusters — Sees only the clusters associated with this workspace (e.g., “Payments-Staging”, “Payments-Prod”). Does not see clusters belonging to other teams.
3. Monitor process instances — Opens the cluster’s Operate view. Monitors active process instances, checks for incidents, reviews execution history.
4. Resolve incidents — Identifies a stuck process instance. Investigates root cause, retries or cancels the job. Documents the resolution.
5. Report performance — Shares process performance metrics with the Team Lead and CoE Lead. Metrics are scoped to the team’s clusters, providing clear accountability.

---

Cross-Persona Flow: New Team Onboarding (End-to-End)

This scenario shows how all personas interact when a brand-new delivery team is onboarded onto the platform.

Step	Persona	Action
1	CoE Lead	Decides a new team needs a workspace. Defines naming, cluster assignment, and governance expectations.
2	CoE Admin	Creates the workspace for the team. Assigns the Team Lead as Workspace Admin. Assigns clusters to the workspace.
3	Team Lead	Receives notification. Opens workspace. Creates a project. Adds Developers and Operations Engineer to the workspace with appropriate roles.
4	Developer	Receives workspace access notification. Opens workspace. Sees only assigned clusters. Starts building BPMN processes, consuming Catalog assets from CoE. Deploys to the development cluster.
5	Operations Engineer	Monitors process instances on the cluster after first deployment. Reports performance back to Team Lead.
6	Team Lead	Requests production cluster access for the workspace.
7	CoE Admin	Approves request. Assigns a production cluster with the workspace.
8	Developer	Deploys to the production cluster.
9	Operations Engineer	Monitors production executions and resolve incidents if they emerge.

---

Cross-Persona Flow: Workspace Request & Rejection

Step	Persona	Action
1	Team Lead	Submits workspace request for “Experiments” workspace.
2	CoE Admin	Reviews request. Determines it doesn’t align with the workspace taxonomy — suggests using an existing “Sandbox” workspace instead. Rejects with feedback.
3	Team Lead	Sees rejection with explanation. Requests access to “Sandbox” workspace instead.
4	CoE Admin	Adds Team Lead to “Sandbox” workspace as Workspace Admin.
5	Team Lead	Configures projects inside “Sandbox,” adds team members.

---

Experience Principles

Principle	How It’s Expressed
Intentional structure	Workspaces are governed by the Center of Excellence (CoE).
Scoped visibility	Every user sees only what’s relevant: their workspaces, their projects, their clusters.
Governed but not blocked	Approval flows exist for workspace and cluster requests, but they’re transparent and fast. Users can track status and get feedback.
CoE governs, Delivery Team executes	The CoE defines structure and policies. Delivery Teams build and ship within those boundaries.