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:

• Owner — the project creator.
• Admin — manages members, sharing, access rules, and approvals.
• Editor — can enter and change cube data.
• Viewer — read-only.

Access rules — scope what a user sees and edits

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

• what they see — only certain dimension items (e.g. only the East region), and
• what they can edit — make some of those items read-only, or let them edit only their own slice.

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.

Comments on a cell

Any cell can carry a thread of comments — the place for the sentence that explains a number to whoever reads it next: the assumption behind it, the source it came from, why it moved. Comments can carry file attachments, and cells that have one show a small indicator in the grid, which you can turn off when presenting.

The assistant writes comments too, and they are a separate layer: an AI annotation is marked as such, and a cell has at most one of them, rewritten rather than accumulated each time the assistant revisits the value. Your own comments are untouched by that, so an annotation explaining how a figure was derived can sit alongside a colleague's question about it.

Comments are not part of a snapshot: restoring one brings the numbers back, not the commentary around them.

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