Three Roles, One Dashboard: What Each Profile Can See and Do in RoomStream
Superadministrator, chain administrator, hotel administrator. Each role sees exactly what it should — no more, no less — enforced at both the interface and the API server independently.
In a platform that manages several hotel chains, and within each chain several hotels, a binary permission model (admin / not-admin) runs out of precision almost immediately. Too much access and you create security problems; too little and people cannot do their jobs. RoomStream defines three distinct roles, each with a different view and a different set of capabilities.
Why Binary Permissions Are Not Enough
Consider the practical situation: a chain IT manager in Madrid needs to manage audio across 12 hotels in Spain, France and Portugal. A hotel operations manager in Mallorca needs to control the music in their specific property. A platform engineer needs to deploy a new agent version to the entire fleet. These are three different jobs with three different levels of access — and giving all of them the same account type creates both security problems and operational noise.
The chain IT manager does not need to see other chains' data, and should not be able to by accident. The hotel operations manager should not be creating new zones or touching device configurations — that is the chain IT manager's job. The platform engineer should not need to interact with individual properties at all. Three roles, three scopes.
Superadministrator
Sees the entire platform: all chains, all hotels, all devices. This is the only role that can publish a new agent version to the full fleet, or manage which chains exist on the system. In day-to-day operation, a superadministrator rarely needs to interact at this level — the platform is designed so that normal management does not depend on this role. It exists for platform-level operations: fleet-wide updates, onboarding new chains, and platform-level diagnostics.
Chain Administrator
Sees only the hotels belonging to their own chain — never those of another. This is the role used by the central IT team of a hotel group. Within their chain, a chain administrator can:
- Create, rename and manage hotels and zones.
- Manage the stream catalogue available to those zones.
- Configure the network template for each hotel.
- Generate installation commands for new devices at any property.
- Access device configuration and activity logs across the entire chain.
A chain administrator cannot see or affect any other chain. This is not enforced only by the interface — the underlying API queries filter by chain, so a direct API call from a chain administrator still returns only their chain's data.
Hotel Administrator
Sees only their own hotel. This role is designed for the operations team at a specific property. Within their hotel, a hotel administrator can:
- Control playback in their zones (stream, pause, volume).
- View device status and activity logs for their devices.
- Change network or audio configuration on their devices.
- Generate and view player access codes.
What a hotel administrator cannot do: create new zones or reassign devices between zones (that is the chain administrator's responsibility), or see any data from other hotels in the same chain. The boundary between "my hotel" and "the rest of the chain" is enforced at the same level as the boundary between chains.
The Golden Rule: Two Independent Enforcement Points
Every permission is checked in two separate places: in the interface (so nobody sees a button they cannot use) and independently in the server (so that even a direct API call, bypassing the normal interface, cannot do anything outside the caller's scope). An interface bug never translates into a real security failure.
Interface-level enforcement prevents confusion. Server-level enforcement prevents security failures. Both are required because an interface can have bugs — and because sophisticated users may interact with the API directly. The server's permission check is the one that actually matters; the interface check is a user experience improvement on top of it.
A Practical Note on Role Assignment
Creating new administrators is intentionally restricted: only a superadministrator can create another superadministrator. A chain administrator can create hotel administrators within their chain, but cannot promote them to chain-level access. This prevents privilege escalation — an administrator cannot grant themselves or others more access than they already have, which is the most common way permission systems get bypassed in practice.
The right access level for every member of your team
RoomStream's three-role model gives chain IT teams and hotel staff exactly the access they need — nothing more.
Learn more about RoomStream →