Users & Roles

Purpose: invite and manage teammates, and control what each of them can see and do.

Inviting users

The primary place to manage your team is the Members page (/members), not a page under Settings. A duplicate, smaller version of the same invite/roster UI also appears inline on the main Settings page (/settings) — either one works; changes made in one are reflected in the other immediately.

1. Go to Members (or scroll to Team Members on Settings).
2. Click Invite (or fill in the Invite Team Member form on Settings).
3. Enter the person's email address and choose a role. The invite dropdown offers Viewer or Admin — Owner is not an invite-time role; a workspace has exactly one Owner, transferred separately.
4. Submit.

CMDash emails an invitation link. It expires after 7 days; pending invites appear in the Pending Invitations list, where you can revoke them at any time. There is no built-in resend button — revoke and re-invite instead.

Bulk import

Settings → (Bulk User Import) accepts a CSV with the columns email,role,name (one row per person) and reports how many were invited, skipped, or errored, with a per-row reason for each. A Load template link fills in a starter CSV. This is not documented anywhere in the old admin guide — it is a real, shipped feature.

Changing someone's role

On the Members page, an Owner or Admin can change any member's role between Admin and Viewer using the role dropdown on that member's row. The change takes effect immediately and is written to the audit log as member.role.changed.

Three things the dropdown deliberately will not do:

• It never appears on the Owner's row. Changing the Owner's role is a transfer, not a role edit — see below. Editing it in place would be the only way to leave a workspace with no Owner at all.
• It never appears on your own row. Ask another Owner or Admin.
• It cannot set Owner. Owner is granted only by a transfer, which also steps the outgoing Owner down in the same action.

Managing the Owner of the account

Every workspace has exactly one Owner, and the Owner is the only role that can transfer that position. The Owner is the account's root: unrestricted access to every setting and every record, sole authority over ownership itself, and the role most external frameworks expect to see named as the accountable party for the workspace.

Who the Owner is

The Owner is whoever registered the workspace, unless it has since been transferred. You can see the current Owner on the Members page — their row carries an OWNER badge instead of a role dropdown. The customer portal's Account page also shows your own role and your organization's name.

Transferring ownership

1. Sign in as the current Owner.
2. Go to Members.
3. On the row of the member who should take over, click Make Owner.
4. Type that person's email address into the confirmation box. The button stays disabled until it matches, and the API rejects a mismatch as well.
5. Confirm.

In one atomic step: the person you named becomes the Owner, and you become an Admin. The action is written to the audit log as member.ownership.transferred.

This is one-way from your side. Once the transfer completes you hold Admin and only the new Owner can transfer the workspace back. That is why the confirmation asks you to type the address rather than just clicking through a dialog.

Before you transfer

• The target must already be a member of the workspace. Invite and have them accept first; you cannot transfer to an email that has not joined.
• Any role works as a target. A Viewer promoted straight to Owner gets the full Owner grant.
• Nothing else moves. Reports, API keys, integrations and evidence belong to the workspace, not to the Owner personally, so none of it needs reassigning.

If the Owner has left and cannot sign in

There is no self-service path for this: the transfer must be started by the Owner. Contact support, who can reassign the role through the platform console (PATCH /admin/tenants/:id/members/:userId/role, which refuses to demote the last Owner of a tenant). Have the workspace name and the intended new Owner's email ready.

Removing a user

Members → Erase removes a member from your workspace and erases their personal data in it — the right-to-erasure (GDPR Article 17) request you, as the controller, may receive about an employee who has left. It cannot be undone, so you type the member's email address to confirm (any letter case).

• Who can erase whom. The Owner can erase any Admin or Viewer; an Admin can erase Viewers. Nobody erases themselves, and the Owner is never erased — transfer ownership first. External assessors and vendor respondents are removed by revoking their access grant instead, so their rows have no Erase action.
• What is deleted. The membership, their sessions in this workspace, their saved views, push subscriptions, notifications, feedback and survey answers, their SCIM group links, and any invitation to or join request from their address.
• What is scrubbed or revoked. Training assignments and organizational role assignments stay (they are your programme's records) but lose the person's name, email address and job title. Their address is taken off scheduled-report and executive-briefing recipient lists. Delegated-admin grants they held here are revoked. API keys they created are revoked: a key belongs to the workspace and acts as no user, but the person who created it saw the raw key and may still hold it — any integration using one of those keys stops working until you issue it a new key. Keys created by other people are not touched.
• What happens to the account. If this was the person's only workspace, their account is anonymised as well: name and email are replaced, and their password, two-factor secret, recovery codes, passkeys, trusted devices, every session, notification preferences and dashboard layout are deleted. The email address can then be used to sign up again, as a new account; the erased account can never sign in, accept an invitation or switch workspace again. If the person still belongs to another workspace, their account stays — one workspace cannot erase another's user. CMDash does not tell you which of the two happened: whether someone belongs to another workspace is not yours to know.
• What is kept. Records they created or signed stay with your workspace: vendors, questionnaires, SBOMs, comments, policy attestations, CMMC affirmations, SPRS submissions, approvals and exercise sign-offs. Those show the anonymised account; attestations, affirmations, SPRS submissions, approvals and sign-offs keep the signer's name, because you may be required to show who signed them.
• The audit log. Audit-log entries keep the account's id, and they are append-only and hash-chained, so erasure does not edit them. Most carry only ids — but some record an email address in their details: the invitation that brought the person in, and their SCIM or single-sign-on (SAML just-in-time) provisioning. Those entries are not removed by erasure; they age out with your audit retention.
• Someone already removed. If your identity provider (SCIM or LDAP) or CMDash support already removed the person from the workspace, you can still erase what the workspace holds about them through the API (DELETE /members/:userId with their id and email). Erasing again after a completed erasure answers "already erased" unless something new about them was recorded since.
• Single sign-on. If the member came from your identity provider, remove them there too. Otherwise the next SCIM push for that address either creates a new, empty account (when the address is in a domain your workspace has verified) or sends them a new invitation; an SSO sign-in provisions a new account the same way. Nothing re-attaches to the erased account.

Members → Download data downloads, as JSON, what this workspace holds about one member — their profile, membership, sessions, and the comments, saved views, notifications, attestations, affirmations, approvals, sign-offs, feedback, audit events, training and role assignments, join requests, delegated-admin grants, API keys they created and the report and briefing lists that carry their address — for an access or portability request (GDPR Articles 15 and 20). The same people who may erase a member may download their data. Each section is capped at 1,000 rows and says when it was cut.

When a whole workspace is closed and purged, the accounts of members who belonged to no other workspace are anonymised the same way before the purge runs.

Seat limits by tier

Seat limits and what happens at the limit are enforced server-side per your subscription tier. If you hit your seat limit, the invite action surfaces an upgrade prompt instead of completing the invite.

Roles

Role management now lives on its own top-level page — Roles (/roles), not under Settings.

Custom roles

Custom roles are available on every tier, not Enterprise-only. The Roles page lets an Owner or Admin define additional roles with per-module permission levels (none / read / write / admin), grouped by feature area (Risk, Compliance, Integrations, Admin, etc.). The page also states, per module, whether that permission column is actually enforced by an API guard — so it never silently overstates what a role can do.

Creating a custom role:

1. Go to Roles.
2. Click Create Role (or the page's equivalent create action).
3. Name it, optionally describe it, and set a permission level for each module.
4. Save.

Assigning it: the Roles page includes a member-assignment table — pick the user and the role from there. (There is no separate "Settings → Roles" route; that page does not exist.)

Guardrails: the API blocks self-assignment of a role that would grant you privileges you don't already have, and blocks removing the last holder of a role that still has members depending on it (SELF_ASSIGNMENT_FORBIDDEN, PRIVILEGE_ESCALATION_BLOCKED in the roles controller).

Related

• Business Units — Enterprise org hierarchy, still a separate top-level page (/business-units).
• Authentication — MFA, sessions, password policy.
• SSO, SCIM & LDAP — automated provisioning from an IdP.