Roles and permissions
Count's permissions model helps teams of different sizes to work flexibly whilst maintaining strong governance over who can access the team's data and analysis.
A user's access is governed by:
- Their workspace role.
- Any groups they are a member of.
- The projects they can access.
- The role they have within each project.
You can view everyone with access to the workspace in the Members tab in the workspace settings.
Workspace roles
There are several workspace roles in Count, which determine the actions workspace members are permitted to perform.
Roles are hierarchical, where Owner is the most permissive role and Guest is the least.
| Role | Manage billing + settings | Manage members | Create connections + projects | Billable | Project roles |
|---|---|---|---|---|---|
| Owner | ✅ | ✅ | ✅ | Yes | Admin |
| Admin | ❌ | ✅ | ✅ | Yes | Up to admin |
| Analyst | ❌ | ❌ | ❌ | Yes | Up to analyst |
| Explorer | ❌ | ❌ | ❌ | Yes | Up to explorer |
| Member | ❌ | ❌ | ❌ | – | Up to editor |
| Guest | ❌ | ❌ | ❌ | – | Up to viewer |
Owners
Owners have full control of the workspace. They automatically have access to every connection and project and always have administrative privileges in each.
By default the creator of the workspace becomes an owner, and a workspace can have multiple owners. Owners are always billable.
Owners can:
- Access and change all workspace settings.
- Create, edit and delete all database connections.
- Have Admin roles in all projects.
- Create projects.
- Manage members and roles.
Owners cannot:
- Change their own workspace role.
- Leave a workspace if they are the only Owner.
Admins
Admins control how data is accessed within the workspace. They manage all database connections and build and manage projects. Admins are always billable.
Admins can:
- Create database connections.
- Be given Admin or Viewer roles within any database connection.
- Create projects.
- Be given Admin, Analyst, Editor or Viewer roles within any project.
- View (but not edit) workspace settings.
- Manage members and roles.
Admins cannot:
- See every project or connection in the workspace by default - they have to be invited.
- Change workspace settings.
- See workspace billing settings.
- Change their own workspace role.
Analysts
Analysts are workspace members that may be given permission to edit code in canvases. Analysts are always billable.
Analysts can:
- Be given Analyst, Editor or Viewer roles within any project.
- View the list of members in the workspace.
Analysts cannot:
- See or edit any database connections by default.
- Be given Admin roles for any project.
- See the Settings and Billing tabs in workspace settings.
Explorers
Explorer roles are not available on all plans.
Explorers are similar to Analysts, but cannot edit SQL or Python cells. The explorer role is billable, and is designed for those members of your workspace with some analytical knowledge but limited SQL proficiency. Low-code cells and visual cells should provide all of the functionality that an explorer needs!
Members
Members are like Analysts, but cannot be granted permission to edit code in any canvases. Members are never billable. If given edit access to a canvas, Members can edit any part of the canvas except for cells and visuals.
Guests
Guests are users who have not been invited to join the workspace but have been given access to specific canvases and projects within the workspace. Guests are never billable.
Guests can:
- Be given Viewer or Report Viewer roles within any project.
- Be given Viewer or Report Viewer roles for a specific canvas.
Guests cannot:
- See any workspace settings.
- See any database connections.
- Be added to groups.
- Be invited to projects or canvases via the "Members of workspace" permission.
Project roles
Within each project every member also has a project-specific role. These roles dictate which project-level actions users can perform:
| Project Role | Manage data + settings | Invite others to project | Create + edit canvases | Edit cells | View canvases | View reports |
|---|---|---|---|---|---|---|
| Admin | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Analyst | ❌ | Depends on project settings | ✅ | ✅ | ✅ | ✅ |
| Explorer | ❌ | Depends on project settings | ✅ | Low-code + visuals | ✅ | ✅ |
| Editor | ❌ | Depends on project settings | ✅ | ❌ | ✅ | ✅ |
| Viewer | ❌ | Depends on project settings | ❌ | ❌ | ✅ | ✅ |
| Report viewer | ❌ | Depends on project settings | ❌ | ❌ | ❌ | ✅ |
Viewers / Report viewers
Viewers / Report viewers can:
- View canvases that are shared with the project (if a viewer)
- View reports that are shared with the project
- View all members of the project
- If allowed by the project settings: share canvases outside the project or invite new users to the project as Viewers (if a viewer) or Report viewers
- Leave the project
Analysts / Explorers / Editors
Analysts / Explorers / Editors can additionally:
- Create, view, edit and delete canvases
- Restore deleted canvases
- View canvas version history
- Edit cells and visuals (if an analyst or explorer)
Admins
Project Admins must have a workspace Owner or Admin role.
Admins can additionally:
- Manage project membership and roles
- Manage available connections
- Update project settings
- Delete the project
If a user has been assigned two conflicting roles then the most permissive role wins.
For example, if a user has explicitly been granted a project viewer role but in addition the project has granted edit access to the whole workspace, then the user will have edit access.
