Roles and permissions

The two levels of access, the roles at each, and how to configure what those roles may do.

Chartizer has two independent permission levels. Almost every access question comes down to knowing which one you are looking at.

Level	Controls	Set from
Team role	Billing, members, the data catalogue, folders, settings	Settings → Members
Project role	One project’s charts, dashboards, files	The project’s Members tab

The roles below are defaults, not fixed

Permissions are configurable. Every capability in the tables on this page can be turned on or off per role, and you can define your own roles beyond the built-in ones — see Custom roles.

Admin is the exception. It is the superuser: it always holds every permission, including ones you add later, and it cannot be restricted.

The two do not cascade

A team Admin can manage every source in the catalogue and still not have access to a project they are not a member of. Being on the team is not being on its work — administering plumbing is not the same as reading results.

Because admins assign roles, one can always add themselves to a project. That is a deliberate action, not an implicit right: it appears in the project’s member list and in the audit trail, so it is visible rather than silent.

The catalogue is team-global, so catalogue rights are too

There is no per-folder control over sources or datasets. Anyone with team Admin can edit any source, and that change reaches every project in the team. Grant team Admin narrowly.

Team roles

Capability	Viewer	Member	Admin
Sign in, open granted projects	✓	✓	✓
Create folders and projects		✓	✓
Create and edit sources			✓
Edit datasets			✓
Invite and remove members			✓
Assign roles			✓
Billing, plan, and payment methods			✓
Manage local agents			✓
Delete the team			✓

Admin is the superuser. It controls who is in the team, what role each person holds, what those roles are allowed to do, and payments. Its own permissions are not editable — an admin always has everything, which is what stops a team from configuring itself into a state nobody can undo. A team can have several.

Every team must keep at least one admin

The last admin cannot be demoted or removed — the action is refused rather than leaving the team with no one able to manage roles or billing. Promote a second admin before changing the only one, and before that person goes on leave.

Project roles

Capability	Viewer	Editor	Maintainer	Owner
Open charts and dashboards	✓	✓	✓	✓
Export data and images	✓	✓	✓	✓
Create and edit charts		✓	✓	✓
Upload files		✓	✓	✓
Add datasets from the catalogue			✓	✓
Create share links and embeds			✓	✓
Manage project members				✓
Delete the project				✓

How they combine

Effective access is the intersection: the team role reaches the feature, the project role reaches the content.

Text

Ana — team Member · project Editor on "Weekly revenue"
  ✓ edit charts in Weekly revenue
  ✓ create a folder and a new project
  ✗ add a dataset to Weekly revenue    (needs project Maintainer)
  ✗ connect a new source               (needs team Admin)

Edgars — team Admin · no role on "Weekly revenue"
  ✓ connect sources, edit datasets, manage the catalogue
  ✓ see that Weekly revenue exists, in which folder
  ✗ open its dashboards                (needs a project role)

Because the catalogue is team-global, Edgars’ work reaches every project in the team even though he can open none of them — and Ana’s charts may read a source she never connected.

Custom roles

The built-in roles are a starting point. From Settings → Roles an admin can edit what each role may do, or create new roles for the way a particular team works.

Action	Notes
Edit a built-in role	Toggle individual capabilities on or off
Create a role	Name it, pick its capabilities, assign it like any other
Duplicate a role	Start from an existing one rather than an empty list
Delete a custom role	Members holding it fall back to the team default

Typical reasons to make one:

An analyst who can create and edit charts everywhere but must never touch a source.
A stakeholder who can open dashboards and export images but not data.
A data engineer who manages sources and datasets but has no interest in dashboards.

Admin is not editable

Admin always holds every permission, including capabilities added in future releases. This is deliberate: if the superuser could be restricted, a team could lock itself out of its own billing and role settings with no way back.

A permission change applies to everyone holding that role

Editing a role re-scopes every member assigned to it, immediately. Before removing a capability, check the member list for that role — the change is not staged and takes effect on their next action, not their next login.

Prefer a new role over widening an existing one

Granting Viewer the ability to export data affects every viewer in the team, including future ones. A separate role makes the exception visible in the member list instead of hiding it in a toggle.

Dataset-level access

Adding a dataset to a project grants that project’s members access to the data, not just the chart. Chartizer therefore treats it as a privileged action:

It requires project Maintainer plus team Member.
Datasets marked Restricted additionally need approval from a team Admin — this is what produces Edgars approved access to CRM Contacts in the activity feed.

See Access requests.

Mark sensitive datasets Restricted

Anything with personal data — CRM contacts, bank transactions — should be Restricted. Otherwise any Maintainer on any project can pull it in without review.

Service accounts

For sources that must outlive an individual, create a service account: a member with no interactive login, used to hold source credentials.

Property	Behaviour
Login	Disabled; holds credentials only
Seat	Consumes one seat
Role	Usually team Admin, no project roles
Ownership	Survives staff changes

Connect sources as a service account

Pair it with a database role that belongs to the service, not to a person — chartizer_reader rather than someone’s own login. It is the single highest-value habit for avoiding Authentication expired the week after someone leaves.