Who can do what in the portal?
Someone is not allowed to do something, and you want to understand how Szenera works out a permission from role and direct permissions for each action.
4 minute readOrganizationUpdated: 10/25/2026
On this page
Before you start
- 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
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.
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.
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
Found what you needed? Then carry on in the portal — or set up an organization first.
Go to the portalTry it free