Skip to content

Workspaces

A workspace is the container your schemas, connections and files live in. Every tenant gets exactly one, created for you at signup, and there’s nothing to set up.

So this page isn’t really about managing workspaces. It’s a read-only view of the access you actually have — which is a more useful thing than it sounds, because it answers a question people otherwise guess at: what can this key see?

What the page shows

The workspace itself — its name, your tier, and the engine connection serving it.

Cubes you have access to. The cubes your current credentials can reach. If your API key was minted with an allowed-cubes list, this is where you see the effect of it. If it wasn’t, you’ll be told plainly that the key reaches everything in the workspace.

Mondrian roles applied. Any Mondrian role bound to the key you’re using. Roles narrow what a query returns inside a cube — restricting a sales rep to their own region, say — as opposed to the cube allowlist, which decides which cubes exist at all from the key’s point of view. See Access control for how roles are defined.

Using it to debug access

When someone says “the API can’t see my cube”, this page settles it in one look. Three outcomes, three different fixes:

  • The cube isn’t listed. The key’s allowlist excludes it. Fix it on API keys by minting a key with a wider list.
  • The cube is listed but queries come back empty. A Mondrian role is filtering the rows. Check the roles panel, then the role’s definition in the schema.
  • The cube isn’t listed anywhere in the tenant. It’s not an access problem at all — check Analyze for a Broken or Unconfigured status.
  • API keys — where the cube allowlist is set.
  • Members — who can sign in and what they can do.
  • Access control — defining Mondrian roles in a schema.
  • Tenant isolation — the guarantees around one tenant’s data never reaching another’s.