Members & Roles

Overview

Workspaces are collaborative. You invite teammates, assign them a role, and that role determines what they can do. This page is about workspace members — people who log into the admin dashboard to manage your site.

Not the same as site members. End-users of your published site (registered visitors, newsletter subscribers, etc.) are a separate system stored in a different collection. They don't touch the admin. See Member Authentication for that side.

System roles

Every workspace ships with five built-in roles. Two of them grant access to the admin dashboard (“platform roles”), three are for end-user classification on the public site (“app-user roles”).

Platform roles (admin dashboard)

App-user roles (published site)

App-user roles are assigned automatically based on the sign-up flow on your public site. You rarely manage them by hand.

Permissions model

Each role carries a set of permissions. Cmssy ships ~50 permissions grouped by domain. A permission is a capability like pages:publish or users:invite.

The Owner role has every permission. The default Member role has a curated subset (create/edit content, view most things, but no settings or user management). To grant more than what Member has, either promote the user to Owner (via ownership transfer) or create a custom role.

Inviting a member

1. Open Dashboard → Users.
2. Click Invite.
3. Enter the invitee's email and pick a role (defaults to Member).
4. Click Send invitation. An email goes out with an accept link.

The new member appears in the Users list with status pending until they accept. If you invite the same email twice, the second invite is rejected.

Inviting is also gated by your plan's maxUsers limit. Check Workspaces for your tier's cap.

Accepting an invitation

The invitee clicks the link in their email. Two paths:

• They already have a Cmssy account — they log in, land on /auth/accept-invitation, and the workspace is added to their account with the assigned role. Status flips to active.
• They don't have an account yet — they're prompted to sign up. After verifying email, they return to the accept flow and the membership is attached to the new account.

A single user can accept invitations to multiple workspaces. They'll switch between them via the workspace selector.

Member status

Every member is in one of three states:

• pending — invited, not yet accepted. Cannot access the workspace.
• active — accepted and functional. This is the default after invitation acceptance.
• suspended — access revoked but record preserved. Useful for temporary lockouts without losing attribution.

Suspended members cannot log in to the workspace until their status is restored to active.

Changing a member's role

1. Dashboard → Users.
2. Find the member, click their row's actions menu.
3. Pick a new role from the dropdown.

Role changes take effect on the member's next request — they don't need to log out and back in. Requires users:edit permission. The Owner's role cannot be changed this way; use ownership transfer instead.

Removing a member

Same menu as role change: Remove from workspace.

Removal is irreversible — if the user needs access again, you have to re-invite from scratch. Their historical content (pages they authored, forms they edited) stays intact. Attribution on those objects remains but the user no longer has permission to edit anything new.

The Owner cannot be removed. Transfer ownership first.

Leaving a workspace

Any non-owner member can voluntarily leave. This is independent of role — even admins can leave.

Dashboard → Users → [your row] → Leave workspace. Or via your account settings menu.

Owner cannot leave without first transferring ownership. The system rejects leave attempts with a clear error.

Custom roles

The two system platform roles cover most cases. When you need finer-grained permissions — e.g. a “Content Editor” who can edit pages but not publish, or an “Analyst” who can only view reports — create a custom role.

1. Dashboard → Settings → Roles → Create role.
2. Fill in:
   • Name (e.g. Content Editor).
   • Access to admin dashboard (platform role) or Site-only (app-user role).
   • Permissions — checkbox list grouped by domain.
   • Color (optional, for quick visual recognition in the Users table).
3. Save. The role is now assignable when inviting or changing a member.

Editing custom roles

Settings → Roles → pick the role → edit name, permissions, or color. Changes propagate to all members with that role on their next request.

System roles are immutable

The five built-in roles (Owner, Member, Guest, App Member, App Premium) cannot be edited or deleted. If you try, the UI rejects the action. Custom roles are fully editable and deletable.

Deleting a custom role

When you delete a custom role, members assigned to it need a new role. The delete dialog prompts you to pick a fallback role — every affected member gets that role before the old one is removed. This prevents orphaned memberships.

Related

• Workspaces — ownership transfer, plan user limits
• API Tokens — how role + isSuperAdmin determines what tokens can do
• Member Authentication — site members (end-users), separate system