Roles and permissions
Who can do what, and how is that actually enforced?
Owner, Admin and Creator drawn as nested envelopes rather than a table, each capability labelled with its exact permission string.
Drag to pan, scroll to zoom, click an element to trace it.
Open full screenWhat to look for
- The three nested boundaries, and that nothing sits outside the outermost one.
- The permission string under each capability — those are the literal constants in the code.
- What is deliberately absent from the Creator envelope.
Read the full explanation
There are three roles and they nest strictly: a Creator can do a set of things, an Admin can do all of those plus more, an Owner can do all of an Admin’s plus more. Drawing them as boxes inside boxes rather than a comparison table makes that containment structural — you cannot accidentally give a Creator something an Admin lacks, because there is no such region on the diagram or in the code.
Every capability box carries the permission string the code checks, so this diagram doubles as the reference for those constants. If you are reading a route handler and see account:write_credentials, this is where you find out who has it.
The Creator boundary is the interesting design decision. A Creator owns the calendar completely — upload media, compose, schedule, cancel — and can watch the fleet and the history. What a Creator cannot do is touch credentials, change the fleet, or retry a device job. Content work and machine work are genuinely different jobs, and the role split follows that rather than a generic read/write axis.
None of this is enforced in the browser. Hiding a button is a courtesy; the control is a server-side check on every request that touches workspace data. A request from someone who is not a member gets a 404 rather than a 403, so membership of a workspace cannot be probed by anyone outside it.
Anyone deciding what to give a teammate, a contractor or a client.