Introduce Workspaces and Projects in Camunda Hub

Value Proposition Statement

Introduce Workspace and Project as first-class organizational concepts in Camunda Hub to better reflect how customers structure teams, ownership, and delivery of process solutions. This evolution aligns the product with the Hub mental model, improves scalability for multi-team environments, and lays the foundation for clearer access control, collaboration, and future enterprise features while preserving backward compatibility and minimizing disruption.

User Problem

Organizational & Platform-Level Gaps

• Clusters are only clearly visible and manageable in Console organizations, not in Web Modeler.
• There is no shared organizational construct that spans:
  • Teams
  • Process modeling
  • Deployment targets
    • As a result:
      • Customers lack a central place for teams to organize work
      • Organizational context is fragmented across tools
• Confusion for customers who:
  • Operate multiple teams or domains
  • Need clear ownership and collaboration boundaries
  • Want to separate where teams collaborate from what gets deployed

Impact on SaaS Customers

• Many SaaS customers create multiple organizations as a workaround to represent teams, environments, or domains.
  • This leads to:
    • Operational overhead
    • Fragmented visibility
    • Poor scalability as organizations grow
  • The absence of a workspace-like construct forces customers to misuse org boundaries for team organization instead of governance and billing.

Target State (Hub Prototype)

• Workspaces represent a top-level collaboration boundary:
  • Teams
  • Departments
  • Business domains
• Projects represent a process solution:
  • A cohesive, deployable set of BPMN, DMN, Forms, and related assets
• Users can clearly distinguish:
  • Where teams collaborate (Workspace)
  • What they build and ship (Project)
• The experience is consistent across Hub (former Web Modeler and Console), reducing cognitive load and improving scalability.

Release Notes

What’s New

• Introduced Workspaces as the primary organizational unit in Web Modeler.
• Renamed existing Projects → Workspaces.
• Renamed Process Applications → Projects.
• Updated UI terminology to consistently reference Camunda Hub.
• Reorganized navigation and labels to reflect the new hierarchy:
  • Org → Workspace → Project → Assets

User Stories

Prototype:
https://camunda-hub-prototype-in-carbon.vercel.app

Workspace

• As a team lead, I want a workspace to represent my team or business domain, so that all related projects and collaborators are organised in one shared space.

• As a workspace member, I want to enter a workspace and immediately understand:

  • Who owns it
  • What projects live there
    so that I can orient myself without external context.

• As a workspace member, I expect a workspace to:

  • Contain multiple projects
  • Define the collaboration boundary for my team
  • Contain projects only (no individual files or folders directly at workspace level)

  Future (out of scope): clear cluster assignment per workspace._

• As a workspace admin, I want collaborators to be represented as members at the workspace level, so that it’s clear who belongs to the workspace and shares responsibility.

• As a workspace member, I expect roles to be managed at the workspace level, not per project.

Project: Process Solution & Delivery Unit

• As a developer, I want a project to represent a single process solution, so that all BPMN, DMN, Forms, and related assets are versioned and deployed together.
• As a developer, I expect a project to allow:
  • Folders
  • IDP assets
  • BPMN
  • DMN
  • Forms
  • RPA element templates (Unlike current process applications, which restrict certain asset types.)
• A project:
  • Does not require a BPMN file
  • May be deployable without BPMN
  • May not be runnable without BPMN (DMN-only scenarios may still work)
• As a project contributor, I expect a project to:
  • Live inside a single workspace
  • Contain all assets required for a process solution
  • Integrate with shared assets from the Catalog (see Catalog Epic)
  • Be the unit of deployment and versioning
• As a team member, I want to work on multiple projects within the same workspace, so that related solutions can evolve independently without fragmenting collaboration.
• Note: The concept of a “main process” has been removed (see Unified Deployment Experience epic).

Navigation & Terminology Consistency

• As a user, I want the product structure to make it obvious that:
  • Workspaces organise teams and collaboration
  • Projects build and deliver process solutions
    so that I do not confuse organisational structure with deployable units.
• As a new user, I want the UI to visually reinforce the hierarchy:
  • Organisation → Workspace → Project → Files So that I understand how everything fits together at a glance.

Migration

• As an existing Web Modeler user, I want my structure preserved after the change, so that everything remains intact and understandable.

Migration rules:

• Existing Project → Workspace
• Existing Process Application → Project
• Individual files in a legacy project are migrated into an automatically created project inside the new workspace
• As an existing project admin (and other roles), I want my role preserved when projects move into workspaces, so that I retain my permissions.
• As a user, I want the Project Admin role renamed to Workspace Admin, so that ownership clearly aligns with the new structure.

Open Items

• Organisation-level roles likely need revision as part of Epic 1 to reflect:
  • New naming
  • Updated scope of permissions

Implementation Notes

Users must be able to:

• Clearly distinguish Workspace vs Project purpose without documentation
• Create multiple projects within a workspace
• Navigate between workspaces and projects intuitively
• Find existing content post-migration without confusion

The UI must consistently reflect:

• Hub terminology
• Organisation → Workspace → Project hierarchy