Roles and permissions
Every member has one role in the workspace. Roles are strictly ordered; each includes everything below it.
| Role | What it adds |
|---|---|
| Viewer | Read all shared dashboards and the data model. Create personal content: private dashboards and QuickViews, visible only to the creator. |
| Editor | Publish and share dashboards, and manage annotations. |
| Data modeler | Author the data model: events, properties, metrics. Manage the warehouse connection and run backfills. |
| Admin | Manage members and roles, workspace settings, and the audit log. |
Personal vs. shared content
The line the roles draw is between your content and the team’s content. Any member, including a Viewer, can build private dashboards and QuickViews, and can clone any dashboard they can see (the copy is private). Owners manage their own creations at any role. Making something visible to the team, publishing, is a separate right that starts at Editor.
This is why handing an analyst-in-training or an external stakeholder a Viewer seat is safe: they can explore freely and build their own views without being able to change anything the team relies on.
The data model is readable by everyone
All members can browse the data model: definitions, formulas, lineage. Authoring stays with Data modelers. When you open the model without authoring rights, the page shows a “Read-only” chip and hides the editing affordances; the formula preview still works. Definitions are meant to be read, that is what makes the numbers auditable.
Per-project overrides
The workspace role is the default everywhere. When one project needs a different rule, an Admin can override a member’s role on that project. One override level is special: None hides the project from that member entirely, in the app and in every list.
Workspace-level rights (members, settings) always come from the workspace role; a project override never grants them.
The same rules everywhere
Permissions are enforced identically in the web app, the API, and the AI chat integration. An AI assistant signs in as its user and inherits exactly that user’s role: it sees the same projects, and its write tools obey the same personal-vs-shared line (a Viewer’s assistant can create private dashboards but cannot publish or annotate). There is no side door.
Audit log
Admins have an audit log of membership events: invites, role changes, project overrides, member removal, and workspace settings changes. Useful for the “who changed this and when” questions that otherwise cost an afternoon.
Next: Invite your team covers getting people in at the right role.