Who Can See What
Most permission systems fail in the same direction: everyone becomes an admin because the alternative is being blocked at four in the afternoon. A model people can actually reason about is one where the interesting question — who can change this — has a short answer.
Permission systems fail in a predictable way.
They start strict. Then somebody cannot do their job at four in the afternoon and gets elevated "temporarily". Six months later everyone is an admin, the access review is a formality, and the honest answer to who can change this pipeline is "anyone, probably".
That is not a discipline failure. It is what happens when a model is too fiddly to reason about, so the only move anyone remembers is to make the problem go away.
Four levels, in one direction
Access runs Profile → Workspace → Project → Data.
Your profile is your email identity, and it is singular. You have one. That profile can belong to several workspaces, and your role in each is independent — being an owner of one workspace grants you nothing in another.
That independence is the part worth noticing. It means an agency, a consultancy, or anyone operating across client boundaries does not have to hold their breath about a role in one place leaking into another. Members are isolated to their workspace, with no cross-workspace access at all.
Five roles, across two levels
At the workspace level, two:
Owner — billing, user management, governance, connector management, custom role definition, and oversight of every project.
Member — normal participation. Can see project names and create new projects. Cannot touch workspace settings, users, subscriptions, governance, API tokens, the Activity Log, or roles.
At the project level, three:
Admin — full control of that project: settings, team, all data operations, connections, workflows, orchestrations, checkpoint approvals.
Editor — build and operate. The whole data library, connections, workflows, orchestrations, checkpoint approvals. Cannot change project settings, manage the team, or configure retention policies.
Viewer — read-only, and specifically: view data library items, download datasets, view connections, view workflow structure, and monitor orchestration status. Cannot edit, run, export, or approve.
The line between Editor and Admin is the one that matters day to day, and it is drawn in a useful place. An Editor can do the work — build the pipeline, connect the source, approve the checkpoint. What they cannot do is change who else is in the room or how long data is kept. Those are governance decisions, not build decisions, and separating them is what stops "I need to add a task" turning into an admin grant.
Default roles cannot be edited, on purpose
The five defaults are immutable. You cannot modify what Editor means.
This is a constraint people push against and it is protecting something real. A role whose meaning drifts is a role nobody can reason about — "Editor" stops being a thing you understand and becomes a thing you have to go and read. Once that happens, every access question requires an investigation, and the elevate-and-move-on shortcut starts looking sensible again.
If the defaults do not fit, you duplicate one as a starting point and build a custom role with granular permissions. Custom roles are a Pro and Enterprise capability. The defaults stay meaning what they have always meant.
Viewers are free, and that is a permissions decision
Charging per person who opens a dashboard is a pricing choice that becomes an access-control problem.
The moment a viewer seat has a price, somebody starts rationing them — and the people cut first are the ones furthest from the budget and closest to the work. You end up with a permission model shaped by procurement rather than by who needs to see the number.
Dashboard viewers are unlimited and free on every plan, including Free — and what they can actually do with a dashboard is more than look at it. So "should this person have access" stays a question about whether they need it.
What you can prove afterwards
The Activity Log records workspace activity and can be viewed and exported for compliance and audit. It is workspace-scoped and, deliberately, not something a Member can reach — an audit log that the audited can read is a weaker artifact.
That matters for the question access control eventually gets asked: not who can see this, but who did.
Where to start
Two things are worth an hour, once.
Check whether your Editors should be Admins. Most people who were made Admin needed to build something, and building is Editor's job. The difference is whether they can change the team and the retention policy, which is usually not what anyone intended to grant.
Decide who holds Owner, and make it more than one person. Billing, governance and role definition sit there, and a single owner is a single point of failure in the least convenient way — usually discovered while they are on leave.
Everything else can wait until it comes up.
