Permissions
The six roles and what each can do, scopes and how a role is resolved, dynamic views, and the single most important thing to understand — that nothing authored here is enforced without a server.
⚠ A schedule with no room — or a copy of the file — carries no restrictions at all: anyone holding it has the whole thing. Roles, scope precedence, dynamic views with per-column grants, row filters and grant reporting are all authored here; evaluation is the server's, per reader, per row, per column, when somebody joins the room, and a client-side filter would be a UI convenience wearing a permission's clothes. Group membership comes from identity and is not held here. No seat or tenant administration, and pushing rules replaces the whole set — two admins pushing at once means last write wins, silently.
⚠⚠ Sequence is where permissions are authored. It is not where they are enforced.
Permission is evaluated server-side, per reader, per row, per column. A client-side filter would be a UI convenience wearing a permission's clothes.
In the beta there is no server, so nothing authored here is enforced by anything. The panel says so in a banner rather than in a tooltip.
The distinction that keeps this honest: the application may answer "what would this person see?" while you are authoring a rule. It may never use that same answer to hide something it has already received — if the client received a row, the server already decided that reader may have it, and hiding it locally would teach an author to trust a filter that stops at the network boundary.
Roles#
Six, most privileged first:
| Role | |
|---|---|
| Owner | Everything, including transfer |
| Admin | Everything except transfer |
| Redline | Edit cells and structure, invite |
| Redline (no share) | Edit, but cannot invite |
| Commenter | Read, export, comment, attach, respond to update requests |
| Viewer | Read and export |
The capabilities a role is asked about are: read, export, comment, attach, respond to an update request, edit cells, edit structure, manage permissions, invite, delete, and transfer.
⚠ The order of the role list is load-bearing — it is what decides a tie when two grants apply.
Scopes#
A grant is made at a scope: workspace, project, sheet, report, dashboard or view.
Where several grants reach the same reader, the least privileged wins. Sequence can explain a verdict rather than merely stating it: which grants were considered, which applied, and why the answer is what it is.
Dynamic views#
A view can be shared such that what each reader receives is filtered by who they are — a subcontractor sees their own packages, not the whole schedule.
⚠ Not every filter is safe to share this way, and Sequence checks. Only a restricted set of operators and column types can express an exposure rule that the server can evaluate soundly per reader; a view built on anything else is reported as not shareable, with the reason, rather than shared with a filter that does not hold.
Two role models, one mapping#
⚠ Sequence's six roles are a superset of the collaboration server's four (owner, editor, commenter, viewer). The mapping between them is written down in the model rather than rediscovered on the wire, so the two cannot drift into disagreeing about what a commenter is.
Related#
- Views & filters — sharing a view is not sharing the sheet.
- History — permission changes are recorded.