Access is decided at three layers, from narrowest to broadest: the **collection**, its **workspace**, and any **organisation** above it. They’re deliberately separate — being in the organisation doesn’t by itself open a workspace’s private collections.

## Collection roles

Each collection grants people one of three roles directly:

| Role         | View | Filter / explore / export | Edit metadata & images | Manage sharing & settings | Delete |
|--------------|------|--------------------------|------------------------|--------------------------|--------|
| **Reader**   | ✅   | ✅                       | —                      | —                        | —      |
| **Contributor** | ✅ | ✅                       | ✅                     | —                        | —      |
| **Owner**    | ✅   | ✅                       | ✅                     | ✅                        | ✅     |

“Edit images” covers the per-image actions (replace, rotate, flip, remove) and metadata re-upload — see [Data tab](/content/docs/data-tab/index.html).

## Visibility vs. roles

Visibility widens _who can view_, independently of the role grants above:

| Visibility | Who can open it |
|------------|-----------------|
| **Private** | Only people with a collection role (or via workspace access). |
| **Unlisted** | Anyone with the link — not listed in public browse/search. |
| **Public** | Anyone; listed in the public gallery and search. |

Public/unlisted grant **view** only. Editing and settings still require a Contributor/Owner role. See [Sharing & publishing](/content/docs/sharing-and-publishing/index.html).

## Workspace roles

A workspace is the container collections live in. Workspace roles govern the workspace and its membership:

| Role         | Use collections (per grant) | Invite / manage members | Manage workspace settings | Delete workspace |
|--------------|-----------------------------|-------------------------|--------------------------|------------------|
| **Member**   | ✅                          | —                       | —                        | —                |
| **Admin**    | ✅                          | ✅                      | ✅                        | —                |
| **Owner**    | ✅                          | ✅                      | ✅                        | ✅               |

Managing members and recovering deleted collections (the **Trash**) is covered in [Workspaces](/content/docs/workspaces/index.html).

## Organisation roles

An organisation groups workspaces for centralized membership and billing:

| Role         | View org workspaces | Invite / manage org members | Plan & billing | — |
|--------------|---------------------|-----------------------------|----------------|---|
| **Member**   | ✅                  | —                           | —              |   |
| **Admin**    | ✅                  | ✅                          | ✅             |   |
| **Owner**    | ✅                  | ✅                          | ✅             |   |

**Key rule:** organisation roles administer the org — they do **not** automatically grant access to the collections inside its workspaces. A user needs a collection role or workspace membership to open a collection, regardless of their org role. See [Organisations](/content/docs/organisations/index.html).

## Putting it together

To give someone access to a collection you can: add them to it directly (Reader/Contributor/Owner), add them to its workspace, or make the collection unlisted/public for view-only reach. Pick the narrowest that fits — collection roles for one dataset, workspace membership for a team that shares many.