# Invite teammates and roles

_Workspace membership, what each role can do, and how to change them._

Canonical: https://snoze.dev/help/invite-teammates-and-roles/

Everyone in a workspace is a **member** with a **role**. The role is the
starting point for what they can reach everywhere in the workspace; sharing on
an individual item can tighten that, or widen it for that one item.

## The roles

Six built-in roles, from most access to least:

- **Owner** — full control of the workspace, including billing and deletion.
  The only person who can change the plan.
- **Admin** — manages members, settings, integrations, and API keys, plus
  everything a Creator can do. Every workspace needs at least one.
- **Creator** — builds the workspace: databases, views, actions, automations,
  and forms. The role for whoever shapes how the team works.
- **Editor** — edits records and pages day to day. Full editing on everything
  shared with them, and can run actions, but doesn't create actions or
  automations.
- **Operator** — runs the work. Sees everything shared with them and runs the
  actions on it, without editing or building.
- **Viewer** — read-only. Sees what's shared with them and changes nothing.

Owner, Admin, Creator, and Editor are paid **seats**. Operators and viewers are
free and unlimited on every plan — see
[Billing and plans](https://snoze.dev/help/billing-and-plans/).

## Operators and viewers

The two free roles differ by one thing. A viewer reads. An operator reads
**and** runs the actions shared with them — clicking **Mark delivered** on a
record, or a button on a dashboard that files a report. The operator runs
something a Creator built; they don't edit the record by hand and they don't
open the automation behind the button.

Neither role edits or builds on its own. When one person needs more — editing a
single database, running one workflow they can't otherwise reach — share that
item with them directly at the level they need. The extra access applies to
that item alone, and it never turns them into a paid seat.

Operator suits the people who do the work without shaping it: field staff,
contractors, support, anyone who needs to act on what the team built.

## Guests and item grants

Someone outside the workspace can be given access to a single item: a page,
database, view, dashboard, canvas or file. The grant is for that item only,
at a level you choose (view, comment, edit, or run), and a grant on a view
reaches the records that view shows. Guests are free and never count as a
seat. See [Share with a public link](https://snoze.dev/help/share-with-a-public-link/) and
[Permissions explained](https://snoze.dev/help/permissions-explained/).

## Custom roles

On the Business plan, Admins can create **custom roles** in **Workspace
settings → Roles**: a named set of permissions to hand out instead of the
six built-ins. A custom role can never grant more than the person creating
it holds.

## Invite someone

1. **Open Members**

   Go to **Workspace settings → Members**. This is where every member and
   every pending invite lives.

2. **Add a member**

   Click **Add member**, enter their email, and pick a role. Send the invite.

3. **Share the invite**

   The invite reaches them by email, and Snoze also gives you a token you can
   **Copy** and pass along directly — handy when email is slow or you're
   already in a chat with them.

Pending invites stay listed under **Pending invites** until they're accepted,
and you can **revoke** one at any time. Once someone has joined, the members
list lets you change their role or **Remove** them — changes apply immediately.

## What the first run looks like for them

When an invited person signs in, Snoze recognizes the invite during onboarding
and offers a **Join your teammates** step showing the workspace and the role
they were invited as. Accepting drops them straight into the workspace with
that role — no separate setup, and everything is collaborative and real-time
from their first edit. Someone who already has a Snoze account simply sees the
workspace appear.

## Choosing roles

Give people the role that matches what they actually do. **Editor** for anyone
producing work day to day, **Creator** for the few who build the databases and
automations everyone else uses, **Admin** for whoever manages members and
settings. **Operator** and **Viewer** cost nothing, so there's no reason to
leave out a stakeholder who needs visibility or a colleague who only needs to
run something.

When two roles both look plausible, start with the lower one. Changing a role
is one click in the members list and applies immediately.

> [!NOTE]
> Roles are workspace-wide; they don't make individual items visible by
> themselves. What someone actually sees is their role combined with each
> item's sharing — [Permissions
> explained](https://snoze.dev/help/permissions-explained/) walks through how those layers work.

For a one-off audience outside the team — a client reviewing one page — skip
membership entirely and use a [public
link](https://snoze.dev/help/share-with-a-public-link/).