Roles and permissions

More than you might want to know about user permissions in Count.

Introduction

Count's permissions model help 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.

  • The projects they can access.

  • The role they have within each project.

You can view all the users with access to the workspace in the Members tab in Workspace Settings. This shows every user's workspace role and which Members are billable (i.e. have at least one Project Editor role).

Workspace roles

There are four types of workspace role in Count.

Members

The Member role gives users general access to the workspace and means they can be given access to projects and notebooks that have been shared with the whole workspace.

By default members are not billable until they have been assigned as an Editor in at least one project in the workspace. Learn more on the pricing page.

Members can:

  • Be invited to any project within the workspace.

  • Be given Editor or Viewer roles within any project they have joined.

  • View the list of members in the workspace.

  • Be able to view notebooks that have been shared with them from a project they can't see.

Members cannot:

  • See or edit any database connections.

  • Be given Admin access to any project.

  • See the Settings and Billing tabs in workspace settings.

Admins

Admins control how data is accessed within the workspace. They manage all database connections within the workspace and build and manage projects. Admins are always billable regardless of their project roles.

Admins can:

  • Create, edit and delete all database connections in the workspace.

  • Create projects.

  • Be given Admin, Editor or Viewer roles within any project they have joined.

  • Be able to view notebooks that have been shared with them from a project they can't see.

  • See the Settings tab in workspace settings.

  • Invite users to the workspace and change their workspace role between Guests, Members and Admins.

Admins cannot:

  • See every project in the workspace by default (they have to be invited).

  • Change settings in the Settings tab in workspace settings.

  • See the Billing tab in workspace settings.

  • Change their own workspace role.

Owners

Owners have full control of the workspace including who can access the workspace and billing. They automatically have access to every connection and project within the workspace and always have Admin privileges in each.

By default the person who creates the workspace becomes an owner automatically, but they can make other users Owners later. Owners are always billable.

Specifically Owners can:

  • Access and change all workspace settings

  • Create, edit and delete all database connections in the workspace.

  • Have Admin roles in all workspace projects automatically.

  • Create projects.

  • Invite users to the workspace and change their workspace role between Guests, Members, Admins and Owners.

Owners cannot:

  • Change their own workspace role.

  • Leave a workspace if they are the only Owner.

Guests

Guests are users who have not been invited to join the workspace but have been given access to specific notebooks and projects within the workspace. Guests can only have a Project Viewer role and therefore are not billable in the workspace. Guests have to create their own Count account to access the notebooks and projects that have been shared with them.

Specifically Guests can:

  • Have a viewer role on any project they have been invited to.

  • Be able to view notebooks that have been shared with them from a project they can't see.

Guests cannot:

  • See any workspace settings.

  • See any database connections.

  • Be invited to projects or notebooks via the "Members of workspace" permission.

Project roles

There are three types of project role in Count.

Viewers

Viewers can:

  • View all published notebooks in the project.

  • View all members of the project.

  • Share notebooks outside the project or invite new users to the project as Viewers (if allowed by the project's settings).

  • Leave the project.

Viewers are unable to:

  • See any data tables within the project.

  • Create their own notebooks or queries.

  • Remove users from the project or a notebook, nor change their permissions.

  • See past versions of a notebook.

Editors

Editors are able to operate fully within the scope of the project - creating, editing and publishing notebooks as they wish. Any users who are Editors in at least one project are billable.

Editors can perform the same actions as Viewers plus:

  • Create, view, publish and delete notebooks in the project.

  • Fork and merge published notebooks.

  • Restore deleted notebooks.

  • View and query the data tables within the project.

  • View and restore previous notebook versions.

Editors are unable to:

  • Add or remove tables from the project.

  • Remove users from the project or a notebook, nor change their permissions.

Admins

Admins have full control of the project. They manage access to the project and its notebooks and can define what database tables can be used within the project from the project's parent connection. Only Workspace Admins and Owners can be Project Admins.

Admins can do the same actions as Editors plus some additional permissions:

  • Invite and remove users from the project.

  • Change user's permissions between admin, editor and viewer.

  • Manage what data tables the project can see from the parent database connection.

  • Change the project's title and description.

  • Delete the project.

  • Control whether (non-admin) project members can share the project and its notebooks with other members.

Admins are unable to:

  • Change their own project role.

How workspace and project roles work together

The table below summarises which project roles users can be given based on their workspace role.

Workspace role

Can be project admin?

Can be project editor?

Can be project viewer?

Can be given access to a notebook without being a member of the project?

Owner

Always

N/A

N/A

N/A

Admin

Yes

Yes

Yes

Yes

Member

No

Yes

Yes

Yes

Guest

No

No

Yes

Yes

Note: If a user has been assigned two conflicting project roles then the most permissive permission wins.

For example, if a user has been explicitly given a viewer role to a project but in addition the project has given edit access to the project for the whole workspace, then the user will have edit access.