Workspaces
A workspace is a container for related schemas. Every tenant gets one default workspace at sign-up, and small teams can usually stop there. The page becomes useful once you’ve outgrown the single bucket — typically when you want to separate prod from staging, or executive cubes from operational ones, or one end-customer’s cubes from another’s.
Workspaces don’t enforce any technical separation between cubes — they’re an organisational layer over your catalog. The real access-control surface is Members, where you grant read or write per workspace per person.
When to create another workspace
A few patterns we’ve seen work well:
Prod and staging. One workspace for cubes powering production dashboards, another for cubes-in-progress. Lock the prod workspace down to a small set of editors so an experiment doesn’t accidentally hit your CEO’s daily report.
Audience-based grouping. Cubes for the leadership team in one workspace, operational drill-down cubes in another. Tighter access on the leadership workspace; broader access on the operational one.
Per-customer separation. Agencies and consultancies running Saiku for multiple end-customers create one workspace per engagement. Members for one customer don’t see another customer’s cubes.
If none of these patterns apply, the default workspace is fine. Don’t create workspaces speculatively — they add overhead in Members bookkeeping.
Creating one
Click Create workspace, name it (anything URL-safe — prod,
staging, client-acme), add an optional description, click
Create. It appears in the list and is selectable as a target
from the Schema designer and
Cube library immediately.
Schemas already saved can be moved between workspaces from the Schemas page.
Granting access
Open Members and pick the workspace from the
access-control section. Add or remove members per workspace; set
their role per workspace. Someone can be an editor in prod and a
viewer in staging, or anywhere in between.