Skip to content

Members and roles

Change a workspace member's role, remove someone, and understand exactly what a removal revokes and what it deliberately leaves alone.

A workspace has exactly two roles, admin and member, and new people always arrive as members. The full split of what each can do is in Work as a team, which is also where inviting people is covered.

This page is the admin side: changing a role, removing someone, and what a removal actually takes away.

Change someone's role

Open Settings, switch into the workspace, and find its Members section. Each row carries the member's role.

Promoting a member to admin gives them everything on the admin side of the role table, including the ability to remove you.

The last admin cannot be demoted or removed

Both refuse:

cannot_demote_last_admin
cannot_remove_last_admin

Promote someone else first, then retry. This also applies to leaving: the last admin of a workspace cannot leave it.

The check and the change happen in a single database transaction, so two admins demoting each other at the same moment cannot both succeed and leave the workspace with none.

Remove someone

Removing a member takes one row out of the workspace. It is not an account deletion, and it is deliberately narrow.

What removal revokes, immediately:

  • Access to the workspace's dashboards.
  • The ability to author against the workspace's data sources. Current membership is required with no exemption, including for the person who added the data source in the first place.
  • Membership of every team inside that workspace. The database enforces that team membership is a subset of workspace membership, so this is automatic rather than something you clean up afterwards.

What removal does not touch:

  • Their Dashies account. It still exists and they can still sign in. If they are a member of another workspace, they keep it.
  • Their personal dashboards. Those were never in your workspace.
  • The workspace's dashboards they created. These belong to the workspace, not to them. They stay, they keep serving, and any remaining member can republish them.
  • A data source they added. It stays, and remaining members keep using it.

Someone who left can still delete or rotate the data source they added

This asymmetry is deliberate and it surprises people, so it is worth stating plainly.

A departed member can no longer author against a data source they added, because using one requires current membership. But they can still delete or rotate it, because that is the warehouse credential they personally contributed and being able to withdraw it after leaving is the correct default. Whatever they could do here, they could also do at the warehouse itself by changing the password.

A current workspace admin can also delete, rotate, rename, resync, or re-test it, so you are never locked out of a data source whose creator has gone.

The real exposure when someone leaves is billing, not permissions. On a workspace warehouse dashboard the plan checked at refresh time belongs to whoever created the data source. If that person's own subscription lapses after they leave, every dashboard bound to their data source pauses at once. See where the check happens. If a leaver owns your team's data source, have a current member create a replacement inside the workspace and repoint the dashboards before their plan runs out.

Removals from your identity provider

If you have SCIM directory sync turned on, deactivating or deleting a user in your IdP removes them from the workspace automatically, with exactly the same effect as removing them by hand. It does not delete their Dashies account either.

Check it worked

  1. The member list agrees. Reload the Members section. A removed person is gone from it; a promoted person shows as admin. This is the authoritative check.
  2. The audit log recorded it. Open the workspace's Security section and read the audit log. A role change reads "changed Sam's role to admin"; a removal reads "removed Sam". Treat a missing entry as inconclusive rather than as failure: administrative audit writes are best-effort, so the member list above is what settles it.
  3. There are at least two admins. Before anyone with the admin role leaves or is removed, confirm the workspace has another one. Otherwise the operation will refuse.
  4. For a removal, confirm from their side. Ask the person to reload Dashies. The workspace should no longer appear in their workspace switcher. Your own view cannot prove this.