XCubes

Collaboration — roles, access rules & approval

XCubes is built for teams contributing to the same model — for example regional managers each entering their own numbers into a shared budget. Three mechanisms work together: roles, access rules, and the approval workflow.

Roles & members

Invite people to a project from the Team Members panel and give each a role:

Access rules — scope what a user sees and edits

For any cube, an admin can give a specific user an access rule that limits:

This is how you open a model up for contribution safely: everyone works in the same cube, but each person only touches their own area. (Access rules are about contribution scope, not security hardening.)

Approval workflow

Contributions can be gated by a review step. The Workflow panel tracks each dimension item (typically a time period) through states:

  1. Draft — an editor is still working.
  2. Submitted — the editor submits it for review (optionally with a comment); the item's cells lock so nothing changes underneath the reviewer.
  3. Approved — an admin approves; the item stays locked as the agreed figure.
  4. Rejected — an admin sends it back to draft with a comment explaining why.

An admin can reopen an approved or rejected item to allow further edits. While an item is submitted or approved, its cells are locked for everyone — that's what makes the figure trustworthy once it's signed off.

How edit permission is decided

When someone tries to change a cell, XCubes checks, in order: is the cell within their access rule's visible area → do they have write permission there → is the item workflow-locked (submitted/approved) → is the cell individually locked. The first failing check blocks the edit with a clear reason.

To share results read-only instead of opening contribution, see Sharing.