Roles and permissions: how access works

Why	Understand the access model before handing out logins: what makes up “what a team member sees”.
Who	The owner putting a team together.
What you’ll get	A clear scheme — “a role (a set of permissions) + category scope = access” — and the ability to read the role editor.
Limitations	The model covers a single property; money visibility cannot be narrowed by categories — both limits are covered honestly below.

Before creating logins for your staff, it helps to know what each of them will see after signing in. Access is assembled from two independent parts: the access group answers “what one may do”, the room-category scope answers “what one sees”. This article covers both parts, the three system roles, and the permission editor.

What access is made of

All access is managed in the “Access (RBAC)” section of the “System” group in the left menu. The page is called “RBAC administration”, and its subtitle sets the frame right away: “Managing access groups, permissions, and user assignments within the current hotel.” Access describes one property — not a network of properties, not a whole company.

Inside are two tabs: “Access groups” and “Users”. They hold the two parts of access:

• An access group is a set of permissions across modules: what the team member is allowed to do. This is what “role” means here; it is configured on the “Access groups” tab.
• Category scope — which room categories the team member sees. It lives not in the role but on the user’s card, on the “Users” tab.

Roles are collected in a table with the columns ID · Code · Name · Permissions · Type · Actions (“Edit”) — both the permission count and whether a group is a system one or your own are visible at a glance.

The three system roles

Out of the box the system ships three roles:

• “Owner” (owner) — all 39 permissions;
• “Manager” (manager) — a set narrower than the owner’s; the exact contents are visible in the editor;
• “Viewer” (viewer) — a view-only role.

On a user’s card the group appears as a name with the code — “Owner (owner)”.

A role’s contents are changed in the “Editing an access group” editor: the “Role code”, “Name” and “Description” fields plus the “Permissions” block. A system role carries a notice above the fields: “System role: the code and name cannot be changed; only the set of permissions can be updated.” The code and name are greyed out — only the permission set is editable. Your own group allows editing every field.

Your own group for your own team is created with the “New group” button — “Front desk”, say: permissions for the Planner and Bookings, no Finance.

Permissions: module × action

Permissions in a group are grouped by 17 modules: “Channel Manager”, “Dashboard”, “Finance”, “Guest data”, “Guests”, “Messages”, “Integrations”, “Online booking”, “Payments”, “Planner”, “Rates”, “Bookings”, “Rooms”, “Services”, “Taxes”, “Templates”, “Users”.

Every permission follows one format — “Module: action — description”: the line shows at once which module the action belongs to and what exactly it allows.

In most modules permissions come in pairs — view and edit. Some modules add narrow actions, and three of them are worth knowing in advance:

• “Messages” — “sending” and “administration”;
• “Users” — “management”, that is, the permission to configure users and their access;
• “Guests” — “Fill in the guest form for the guest” and “Decrypt the guest form’s personal data”: both permissions are about passport data from the guest form, and are best granted selectively.

The “Permissions” block in the editor is convenient: it has a search over permissions, an “N/N” counter for each module, and the “Clear all” / “Select all” buttons.

Visibility by category — not by role

Looking for category visibility in the role editor is pointless — it is not there. The model’s principle: a role governs actions, not “which rooms are visible”.

The category cut is set on the user’s card: the “Users” tab → the “Set up access” button → the “User access settings” screen. Besides the name, login, “Property” and “Access groups”, it holds a ‘Scope for the “Rooms” module’ block with the “Scope mode” field:

• “All categories” — the hint below explains: “The user sees all categories of the selected property.”
• “Selected categories only” — only the picked list of categories is visible.

A classic example is a housekeeper: she does not need a dedicated “sees her floor only” role. Any role plus the “Selected categories only” mode listing her floor’s categories is enough. The same mechanism covers the unit owner’s access: an apartment unit is a category, and a scope of one category leaves the owner their apartment.

Money and roles

The “a user sees only their own money” rule does not work in the system — do not build your access scheme on it. Finances are limited by permission only: with the “Finance” module permission, the whole money flow of the property is visible; money has no category cut, and category scope does not affect it.

So pairs like “the housekeeper sees her floor’s money” or “the unit owner sees payments for their apartment only” cannot be assembled: either the “Finance” permission — and the full picture, or no permission — and no money.

The action journal

The journal shows who changed what: “Logs” → “Application log” — “View working actions, system events, and errors with filters by time, user, and entity.”

Access is no exception here: creating a user leaves a USER_CREATED event, changing their access — USER_ACCESS_UPDATED. The quick path to them is the “Access” filter chip. For the owner this is a ready answer to “who changed a team member’s permissions, and when”.

See also

• Staff: create a login and set up access — create a login, assign a group, change a password.
• Unit owner access — the “Selected categories only” mode at work: a manager sees only their apartments.
• How guests’ passport data is protected — what stands behind the “Fill in the guest form for the guest” and “Decrypt personal data” permissions.
• Money in the property: where it lives — where the payments land that the “Finance” permission opens up.