Why your menu differs from a colleague's

Who this is for: Owner and Manager — diagnosing this needs no permission; changing a role requires org.roles.manage, and switching an app on requires apps.manage.

Two people at the same hotel see different menus, and both are correct. This is the single most common thing new teams ask about, so it is worth understanding once rather than raising three tickets about.

Three things must all be true for a screen to appear in someone's sidebar:

1. Their role carries the permission that screen requires.
2. The app that owns the screen is enabled on that property.
3. They are in a context — an organisation and a property — where that role applies.

A missing menu item is always one of those three.

Work out which one is missing#

Start with the person who cannot see the screen, in the context where they expect it.

1. Check the context. Look at the property switcher in the sidebar header. Is it naming the property you both mean? A Manager at one organisation and read-only at another has two different menus, correctly.
2. Check the app. Open the Dashboard and read Enabled apps. If the owning app is not listed, the whole group is absent for everyone at that property, whatever their role. An Owner switches it on — it is per property, so it doubles as a feature gate.
3. Check the permission. Read the Your permissions card on the same Dashboard. It is the literal, server-resolved set. Every page in these docs names its screen's permission on its first line; compare the two.

If all three line up and the item is still absent, that is a bug worth reporting — with a screenshot of the Dashboard.

Know what a role is#

A role is a bundle of permissions granted to a member at a scope. Nerve ships five — Owner, Manager, Front Desk, Accountant, Read-only — and they are configurable per organisation: what your house calls Manager may not be what the defaults call Manager.

So phrase questions in terms of the permission rather than the role name. "Does Sam hold frontdesk.checkin?" has an answer; "is Sam a Manager?" does not, quite.

The full default bundles, and the permission behind every screen, are in roles and what each one can do.

หมายเหตุ

A member can hold more than one role, and the result is the union of them. Adding a second role can only ever add permissions, never remove them — which is why granting an extra role is a safe way to unblock someone quickly, and a poor way to restrict them.

Understand what hiding does and does not mean#

สำคัญ

The sidebar is a convenience. It is not the security boundary.

The menu is built on the server from the resolved permission set, and every screen behind it enforces the same permission independently. Typing a URL you have no permission for returns an unauthorized state — one that does not reveal whether any data exists behind it, so probing a URL tells an outsider nothing.

That also means the reverse is safe to rely on: if you can see a screen, you are meant to be able to.

Choose a role when you invite someone#

A quick starting map — the defaults, which your organisation may have changed:

The person	Start with
Runs the company	Owner
Runs the hotel day to day	Manager
Works the desk	Front Desk — which also carries the Housekeeping board
Keeps the books	Accountant
Needs to look, not touch	Read-only

Scope the membership to one property when the person only works at one. It is the cleanest way to make sure their menu is the menu they need.

เคล็ดลับ

Grant the narrow role first and widen it when someone asks. Widening is one edit; discovering months later that a desk agent could edit rates is a conversation.

What's next#

• Roles and what each one can do — the full default bundles and the permission behind every screen
• Sign in and find your way around — reading the sidebar and the Dashboard
• Your first week on Nerve — where inviting the team sits in the setup order