# Roles (/docs/guides/roles)

People belong to an **organization** with one role, managed on [www.obelism.studio](https://www.obelism.studio) for every Obelism product. The role applies to every space of the organization.

| May…                                                          | Admin | Developer | Editor | Reader |
| ------------------------------------------------------------- | :---: | :-------: | :----: | :----: |
| Read content, the model, assets, locales and the preview URL  |   ✓   |     ✓     |   ✓    |   ✓    |
| Comment on entries                                            |   ✓   |     ✓     |   ✓    |   ✓    |
| Create, save, publish, move and delete entries; upload assets |   ✓   |     ✓     |   ✓    |        |
| Prompt, save and publish on the site                          |   ✓   |     ✓     |   ✓    |        |
| Promote content between environments                          |   ✓   |     ✓     |   ✓    |        |
| Promote the content model along                               |   ✓   |     ✓     |        |        |
| Export and import content (backups, moving content)           |   ✓   |     ✓     |        |        |
| Change the content model                                      |   ✓   |     ✓     |        |        |
| Create spaces; change locales, preview URL, prompt endpoint   |   ✓   |     ✓     |        |        |
| Open Settings and Activity                                    |   ✓   |     ✓     |        |        |
| See, create and revoke API tokens and webhooks                |   ✓   |     ✓     |        |        |
| Invite and remove members, rename the organization            |   ✓   |           |        |        |
| Roles per space; reviewed publishing, and approving reviews   |   ✓   |           |        |        |
| Transfer or delete a space                                    |   ✓   |           |        |        |

## Roles per space [#roles-per-space]

By default a member has their organization role in every space. An admin can give someone a role in some spaces only, under **Settings → People**: from then on they only see the spaces they have a role in, with that role in each (developer, editor or reader; it can be more than their organization role, say a client's editor who is a developer in their own space). Agencies use it to give a client's people their own space and nothing else.

- **Every space, as …** puts someone back in every space with their organization role.
- **Not in this space** takes one space away, but not their last: choose every space, or remove them from the organization on www.
- Admins are always in every space; to restrict an admin, change their role on www first.
- Everything follows the role in the space: the dashboard, the agent API and MCP, management and site tokens (as their creator) and editing on the site. Spaces someone wasn't given don't show up anywhere, as if they didn't exist.

Agents use `GET …/spaces/{space}/members` and `PUT …/spaces/{space}/members/{userId}` with `{ "access" }` (admins).

In an environment whose publishing is **reviewed** (Settings → Publishing), only admins publish, unpublish, schedule, delete published entries and promote or import published content there; developers and editors [ask for review](/docs/guides/publishing#review-before-publishing) instead, and an admin approves or sends it back. Changing the setting is for admins too.

## Access per product [#access-per-product]

An admin can keep a member out of Content (or out of Improve) on www, under the organization's **Product access**. For Content they are then no member at all: the organization doesn't show up, and its spaces answer as if they didn't exist, in the dashboard, the agent API, MCP and their tokens. Their role and access to the other products stay as they are. Agents use `PATCH https://www.obelism.studio/api/agent/organizations/{org}/members/{membershipId}` with `{ "products": ["improve"] }`, or `null` for every product (admins).

An admin can also turn Content off for the organization on www. The dashboard, the agent API, MCP and the management API then refuse it (`product_disabled`), while delivery keeps serving your sites.

## Tokens and agents act as a person [#tokens-and-agents-act-as-a-person]

- **Management tokens** and **site tokens** act as the person who created them, with that person's role at the time of each request: they stop working when the person leaves, and lose rights when the role changes.
- **MCP** and the **agent API** run as the person who signed in.
- **Delivery** and **preview tokens** only read, and belong to the space environment, not to a person.