---
title: Members and roles
description: Change a workspace member's role, remove someone, and understand exactly what a removal revokes and what it deliberately leaves alone.
updated: 2026-08-05
tier: pro
---

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](/guides/work-as-a-team#roles), 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:

```bash
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.

:::warning{title="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](/concepts/plans-and-gating#where-the-check-happens-and-when).
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](/admin/scim) 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](/admin/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](/admin/audit-log#what-it-does-not-cover), 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.