# Permissions

> Every permission an Endless workspace enforces, what each one lets someone do, and which of the four roles holds it by default, in one reference table.

Source: https://endless.app/docs/reference/permissions

Endless checks eleven permissions before it lets an action through. Which ones a person
holds comes from their role. Every workspace starts with the same defaults, shown below; where
custom roles are turned on, an admin can change them for Member, Billing manager and Viewer.

This table is generated from the permission catalog itself, so it can't fall behind what
the product actually enforces. [Roles and permissions](/docs/governance/roles-and-permissions)
explains the same list in prose, with the reasoning behind each one.

<Callout type="info">
  Without custom roles, a role is a fixed set of abilities: there's no screen
  for handing a Viewer the ability to create content, so this table is the whole
  story. With them, it's the starting point an admin tunes from. Nobody can take
  anything away from Admin.
</Callout>

<PermissionTable />

## Admins hold everything

Admin is locked to the full list and can't be narrowed. That's the floor that stops a
workspace configuring itself into having nobody who can manage its own settings — and it's
why granting or removing Admin requires being an admin yourself, and why the last admin
can't be demoted or removed.

## Two pairs that look like one

Four rows above come in pairs, and the split is deliberate.

**Viewing governance and changing it are separate.** One permission opens the oversight
surfaces — activity, and which models, features and tools each person can use — and reads
them without touching anything. The other is what actually turns those things on and off.
Kept apart so oversight can exist without the power to reconfigure: an auditor, a
compliance reviewer, a team lead who should see everything and adjust nothing. By default
only Admin holds either.

**Editing someone else's work and deleting it are separate.** One permission covering both
would mean that trusting somebody to remove a colleague's work quietly also let them
rewrite it. So they're two rows, and a role can hold one without the other.

The "created by others" permissions reach only projects, skills and scheduled tasks the
holder can already open, plus connectors and published sites. They never reach chats,
canvases or [assets](/docs/concepts/assets-and-visibility), and never change who has access.
Those follow sharing instead: whoever made something is its owner and can share it as
**Can view** or **Can edit**. Can edit lets someone change it, as long as their role holds
"Create and edit content"; only the owner deletes it or decides who has access.

## Where roles come from

Roles are assigned per person, per workspace, in **Settings → Members**. Everything about
inviting people, changing someone's role, and what each role sees in Settings is in
[Workspaces and members](/docs/concepts/workspaces-and-members) and
[Roles and permissions](/docs/governance/roles-and-permissions).