Permissions by role and by area

The complete overview of what Owner, Manager, and Member may do in each area of the portal — plus, for each area, a table of which task depends on which permission.

How to read the tables: A check mark (✓) means “may perform this task,” “read-only” means “view yes, change no,” and a dash (–) means “not through this role.” A dash is not a final no: the same task can be opened up through a direct permission or a custom role. The names in the Permission column are the plain-language names under which the permission picker lists the permission.

What the three roles may do#

Two things follow from this table and are immediately visible in the portal: The sidebar shows only the areas for which your account holds a permission, so by default a Member sees five entries. And an area you may only view is marked Read-only., often with the addition “You can view these details. Changing them is reserved for owner and administrator accounts.”

Media#

Scenes, playlists, and programs#

A published scene version is immutable. Resetting only replaces the draft with an earlier state, and that state does not reach the displays until the next publish. Resetting has no permission of its own. It requires Publish scenes, and Edit scenes is not enough.

The two read permissions are deliberately at the top of the table: Without them, Scenes does not appear in the sidebar at all. A Member does not hold them by default. If someone should only be allowed to read content, create the Template “Content reader” on the Roles tab. The same applies to playlists and programs, whose read permissions work in the same way.

Displays, devices, and video walls#

There is no permission of its own for a display’s map position. It is part of the display’s master data and therefore depends on Edit players. Anyone who may change the name may also correct the address. Manage tags is separate from this, since it applies to all displays at once.

Apps#

Installing an app adds its permissions to the permission catalog of your organization, and they are then available in the permission picker.

Analytics and change log#

Advertising and proofs#

Approving a creative is a permission of its own, separate from managing it: Only with it does a creative reach a display. Participation in the ad network is an agreement between the organization and Szenera and therefore lies solely with the Owners. In the permission picker, the advertising permissions are listed under Advertising, and the two proof permissions under Reports.

Billing#

Organization and settings#

API keys and webhooks#

That is why the roles table shows “read-only” for the Manager next to Webhooks: The Manager sees the configured addresses and their deliveries, while creating, changing, and deleting stays with the Owner. A Manager who needs both gets the three permissions through a custom role.

Team#

How permissions are named outside the portal#

Besides its plain-language name, every permission carries a fixed key made up of area, object, and operation, such as identity.user.invite. You do not encounter it in the portal, where the plain-language name appears everywhere. It becomes visible as soon as you work through the API or the command line: A rejected request names the missing permission in its error data, in the field missing, and anyone who creates or changes a role that way specifies its scope as a list of these keys. For the tasks around team, roles, and direct permissions:

All other permissions follow the same pattern: scene.publish for Publish scenes, fleet.player.update for Edit players, webhook.create for Create webhooks. Permissions that come into your catalog with an app carry that app’s own area in the key.

Related#

• Who can do what in the portal?
• Manage members: change role, block, remove
• No access, a grayed-out button, a locked area