Skip to content

Workspaces and roles

OpenCrowd adapts the interface based on who signs in. The same deployment can support administrators, project managers, HR users, auditors, and regular users without exposing every workflow to every person.

Role-based views

Role Keycloak role name What they see Primary purpose
Admin manage_connectors Full dashboard and all features System administration and connector management
Project Manager / Service Manager project_manager My Projects, Groups, Access Matrix, Requests Manage project teams and access
HR manager plus HR configuration Identity, Lifecycle, Groups, Requests Onboard, move, and offboard employees
Auditor approve_requests Reports, Certifications, Compliance, Audit Compliance review and access audit
Regular User Default user Dashboard and Request Access form Submit access requests

The exact navigation depends on the enabled edition, tenant configuration, and permissions assigned by your organization.

Assign a role

  1. Open the Keycloak administration console for your OpenCrowd deployment.
  2. Select the OpenCrowd realm.
  3. Open Users and choose the user account.
  4. Open Role Mappings.
  5. Assign one of the supported roles, such as manage_connectors, project_manager, manager, or approve_requests.
  6. Users without special roles receive the regular user view.

Only authorized administrators should change role mappings.

Project Workspaces

A workspace is a project-level governance view that lets a project manager manage team access across connected applications from one place.

A typical workspace flow looks like this:

  1. The project manager opens My Projects.
  2. They create a workspace and choose the connected applications, such as xWiki, OpenProject, and Nextcloud.
  3. They add team members and choose the required permissions.
  4. OpenCrowd creates a workspace group, adds members, grants permissions, and syncs the changes to connected applications.
  5. The workspace card shows members, connected apps, permissions, and quick actions.
  6. When the project ends, archiving the workspace revokes permissions and disables the project group.

What happens behind the scenes

Action in Workspace What OpenCrowd does
Create workspace Creates a ws-* group, adds members, and grants permissions in the Access Matrix
Add member Adds the user to the workspace group and syncs membership to connected apps
Remove member Removes the user from the workspace group and revokes app access
View permissions Shows the Access Matrix filtered to this workspace group
Archive workspace Removes permission entries and marks the group inactive

How workspaces connect to existing features

Workspaces are not a separate governance model. They are a project-manager-friendly view on top of existing Groups and the Access Matrix.

Workspaces page
  reads groups starting with ws-
    -> Groups
       ws-project-mercury
       ws-project-neptune
    -> Access Matrix
       workspace group -> application -> permission

This keeps governance centralized while giving project managers a focused way to manage day-to-day project access.

Project Manager view vs Admin view

User type Typical navigation
Project Manager My Projects, Groups, Access Matrix, Requests
Administrator Dashboard, Applications, Identity, Groups, Access Matrix, Workspaces, Access Profiles, Requests, Audit, Reports, Settings, and enterprise controls

Project managers get enough control to manage their project teams. Administrators keep the full system view, connector control, and audit oversight.

Why workspaces matter

Without a workspace model, project access often depends on IT tickets and manual updates across multiple applications. With OpenCrowd Workspaces, project managers can request or manage the right access faster while OpenCrowd keeps audit evidence, centralized governance, and consistent access controls in place.