Skip to main content

Members and Permissions

A group can have many members. Each member has a set of permissions that control what they are allowed to manage, so you can give analysts read-and-run access while keeping connection credentials and billing locked down.

Adding members​

Invite a person to the group by their account. Once added, they can switch into the group and access its queries and dashboards according to their permissions.

Plan requirement

Adding extra members and editors requires a paid plan. The Free plan is a single-user workspace (1 user, 1 editor); the Team plan allows up to 10 users and 3 editors, and Enterprise up to 30 users and 10 editors. See Plans and limits.

Permission flags​

Members are granted individual rights in Group settings → Users:

  • Editor — the member can create, edit, clone, delete and share the group's queries and dashboards, schedule queries, publish or discard drafts and see the SQL. Editors also manage the group: its members and their rights, tags, database connections, snippets, IP whitelist, thresholds and log level. Without this right, the member has view-and-run access.
  • Manager — without edit rights, the member can manage the sharing of the group's queries (sharing on or off, link password, expiry, custom link) and write their internal notes. A manager never sees the SQL of the queries.
  • Billing — the member can view and manage the group's subscription and billing.

The owner (creator) of the group has all of these rights. You toggle each right per member, so permissions are additive and explicit rather than tied to fixed roles. Changes to a member's rights and tags apply at the member's next request, in the app and through the API.

Member tags​

You can attach tags to members. Tags are colour-coded labels useful for grouping people (for example, by team or responsibility) and for filtering.

Which queries a member can reach​

  • A member only reaches the queries of the groups they belong to.
  • Member tags restrict access: when a member without edit rights has tags, they can only see and run the queries that carry at least one of those tags — in the app, on public query API calls of queries that are not shared (made with the member's Basic Auth credentials) and through the MCP server.
  • Only editors can see? (a query setting) hides the query from members without edit rights in lists and search. It is a visibility setting, not an access restriction: such queries can still be run by other queries' buttons and imports, and by a member who opens them directly. The MCP server and its REST API do not run them for members without edit rights. Use member tags (or a separate group) when a query must not be reachable at all.

Removing members​

Removing a member revokes their access to the group immediately. Their queries and dashboards remain in the group — ownership stays with the group, not the individual.

Best practices​

  • Grant Billing to as few people as possible.
  • Give read-and-run access (no Editor) to viewers who only consume reports.
  • Use tags to keep large member lists organised.