# Who can do what in the portal?

Roles and permissions decide which areas an account sees and which buttons it may use. The platform recalculates where a permission comes from for every single action.

> **Type:** concept
> **For:** anyone who grants access or wants to know why something is blocked
> **Prerequisite:** an account in the portal. To assign roles, you usually need the **Owner** role.
> **Where in the portal:** **Team › Roles**

## Three built-in roles

An account carries exactly **one** role. Three ship with the portal. The portal itself describes them on the **Roles** tab:

| Role | Description in the portal |
|---|---|
| **Owner** | “Carries the organization: contract and invoices, access and roles, content and devices. The only role without a limit.” |
| **Manager** | “Runs day-to-day operations in full — create, change and delete content, operate displays, view team and contract. Nothing that permanently changes people, money or device inventory.” |
| **Member** | “A read account for operations: dashboard, displays and apps, plus their own account. No administration, no content editing.” |

The line between the first two: The Manager handles day-to-day operations completely, while the Owner is responsible for people, money, and device inventory. Changing billing, managing the team, installing apps, and resetting a display therefore stay with the Owner. Managers may view the team and the contract. The three are stored as `OWNER`, `MANAGER`, and `MEMBER`. That is how they appear in the **Change log** and in error messages.

**Member** is deliberately lean: the sidebar then shows five entries — **Dashboard**, **Displays**, **Apps**, **Notifications**, and **Settings**. If someone should also be able to read content, create the **Template “Content reader”** with one click: “Member plus read access to media, scenes, playlists and schedules”. Built-in roles are read-only. You adapt the usual case with a custom role.

## How a permission comes about

Permissions are not hardwired into the role. The platform recalculates them for **every** action, from the account’s role and direct permissions. The portal shows and hides buttons only as a best guess. If a permission is missing, the button stays visible but grayed out, and a tooltip names the reason. An area for which the read permission is missing does not appear in the navigation at all.

![Flow of a permission check: first the platform checks whether a deny applies, then whether the role or an allow covers the action.](/docs/organization/bilder/0870ad3d-how-a-permission-arises.svg)

## Custom roles and direct permissions

If the three are not enough, create custom roles. You pick their permissions in the permission picker. It shows the catalog for your organization, with every permission described in plain language. The catalog grows with you: when your organization installs an app, that app’s permissions are added.

Alongside them are **Direct permissions (grants)**: “Fine-grained permissions on individual resources; deny always wins.” They apply to a single object, that is, a **Scene**, a **Playlist**, a **Schedule**, a **Display**, or a **Media item**, as **Allow** or **Deny**. An allow works in addition to the role, and a deny beats both.

## What follows

- **You can only grant what you have yourself.** The portal blocks roles that are too large and gives the reason: “You can only assign roles whose permissions you hold yourself.” Only an Owner can assign **Owner**. The last Owner keeps the role.
- **Fewer permissions means a downgrade.** “There is always exactly one role. To grant less, downgrade the account to Member.” If an account carries no role, its access remains and only its direct permissions apply.
- **If the effect does not match the role, check the direct permissions.** A permission that survives a role change comes from an Allow, and a block despite a fitting role comes from a Deny.
- **Graduated access depends on the package.** In the Starter package, every member has full access. The **Roles** tab there shows **Read-only.** and the note “Managing roles starts with Pro.”

## Related

- [Permissions by role and by area](/docs/organization/permissions-by-role)
- [Create custom roles and grant direct permissions](/docs/organization/custom-roles)
- [No access, a grayed-out button, a locked area](/docs/help/access-troubleshooting)