Pengaturan

Roles and what each one can do

The default role bundles, what each can and cannot reach, and how role, permission and app enablement combine to decide your sidebar.

Terakhir diperbarui 21 Agustus 2026

Who this is for: Owner, Manager — managing roles requires org.roles.manage.

The default roles that ship with a Nerve organisation, and the boundary of each.

How to read this#

Three things decide whether you can reach a screen, and all three must be true:

Your role carries the permission that screen requires.
The app that owns the screen is installed on the property.
You are in a context — an organisation and a property — where that role applies.

That is why two people with the same role can see different sidebars: app installation is per property, so it doubles as a feature gate. A screen you cannot reach is not hidden-but-present; the navigation is built from your resolved permission set, and a direct URL to it returns an unauthorized state that does not reveal whether any data exists behind it.

Roles are configurable per organisation. The table below is what each role carries by default — authoring your own is a short job once you know what the defaults leave out.

Penting
Every permission belongs to an app, and an app that is not installed makes its permissions inert. Not hidden — inert: the permission stays in your bundle and stops counting for anything. This is the single most confusing thing in this page, because it means a role can hold a permission and still be refused, and the refusal looks identical to not holding it. The live example on a default property: Revenue is not installed by default, so every rms.* grant a Manager holds does nothing until it is installed.

apps.manage — the permission that installs and removes apps, at Integrations → App Directory — is deliberately a core permission, exempt from this trap: it is always resolvable, precisely so the one screen that turns an app on can never itself be locked behind an app that needs turning on. Manager holds it by default; that is the "app enablement" line in the table below. Installing and enabling apps for a property is the whole story, including the separate, commercial paywall a specific app can still sit behind even when the permission is held.

Catatan
Headquarter is a special case: every one of its permissions is Owner-only by default, anchored on org.manage rather than on any operational permission. A Manager who can run every other app in the sidebar still cannot create a headquarter group, invite a property into one, or read a roll-up — that is not an oversight, it follows the same anchor as Operator Links and the Organisation profile. See Headquarter overview.

Default role bundles#

Role	Can	Cannot
Owner	Everything in the permission catalog	—
Manager	Front Desk (all) — including a reservation's segment/source/purpose, cancellation reasons and special requests — Housekeeping, bookings read and write, room categories, rate plans and prices, distribution settings, listings, messaging, reviews and content, ledger read, Revenue including accepting recommendations, authoring plans and managing the competitor set/benchmark rates, Inventory end to end including both of its gates, Point of Sale end to end including outlet profiles, settlement bank accounts (add, deactivate, reveal), billing setup — charge codes, tax and billing-instruction templates, member invite and management including departments, property create and settings, terminology, notifications, step-up policy, audit read, installing or removing an app from the App Directory	Push availability, set restrictions or stop-sell, manage channels; payables, receivables, night audit; role management; the organisation profile, operator links and the delegation roster; API keys, webhooks and MCP connections inside Integrations; Headquarter, entirely
Front Desk	Reservations — including its segment/source/purpose attributes, cancelling with a reason, and special requests — check-in and check-out, room assign and block, folio post and transfer (including applying a billing-instruction template to a group), payments and refunds, invoices, guests, Housekeeping status	Everything else — no Accounting, no Settings beyond reading billing setup, no Members
Accountant	Ledger, chart of accounts, payables create and approve, receivables, night audit, settlement bank accounts (add, deactivate, reveal), billing setup — charge codes, tax and billing-instruction templates, reservation read, and Inventory's two money gates — approving a purchase order and matching a supplier invoice — plus the stock valuation	Front-desk mutations, Reservations, Revenue, Settings beyond billing setup, Point of Sale, Headquarter, the App Directory; the Inventory catalog, suppliers, receiving, recipes, consumption and counts
Storekeeper	The back-of-house cost side day to day: the stock catalog, suppliers and price lists, raising purchase orders, receiving goods, recipes, issuing stock and running counts, and reading the valuation	Approve a purchase order or match a supplier invoice — the two points where money is committed. Everything outside Inventory
Read-only	Read reservations, rates, bookings, messages, reviews, ledger, analytics, forecast, recommendations, the competitor set and benchmark rates, and the stock catalog, purchase orders and valuation	Any mutation; settlement bank accounts and Headquarter, which it cannot even read

Catatan
The Manager line surprises people in both directions. A Manager may change a room's price — crs.rates.write is in the bundle — but may not push that price to a channel, close a date, or connect a channel. The boundary is not reading versus writing; it is changing what you sell versus changing what the channels are told. The Reservations overview explains why, and rate recommendations covers the one action that crosses the line in a single step.

Catatan
Storekeeper and Accountant are two halves of one job. Read their rows against each other: the Storekeeper orders the goods and puts them away, and the Accountant decides the order was worth placing and the invoice deserves paying. Neither can walk the whole procure-to-pay chain alone, which is the point of splitting them. There is no seeded Storekeeper demo account, but the role ships with every organisation.

Permissions behind the Front Desk screens#

Screen	Permission
Reservations	`frontdesk.reservation.read` to see and record segment/source/purpose, `frontdesk.reservation.write` to change them, cancel with a reason, or add/remove a special request
Room Rack	`frontdesk.room.assign`
Rooms & Units	`frontdesk.room.block`
Guests	`frontdesk.guest.read`
Arrivals & Check-in	`frontdesk.checkin`
Departures & Check-out	`frontdesk.checkout`
Folios & Billing	`frontdesk.folio.post`
Group Billing	`frontdesk.folio.post` to view, `frontdesk.folio.transfer` to route a stay or apply a billing-instruction template
Payments	`frontdesk.payment.take`
Stay-Time Policies	`frontdesk.reservation.read`
Ancillary Catalog	`frontdesk.ancillary.sell`
Room Status Board (Housekeeping)	`housekeeping.status.update`

Permissions behind the Revenue screens#

Screen	Permission
Forecast & Pace	`rms.forecast.read`
Planning	`rms.analytics.read` to read, `rms.plan.manage` to author
Grain & Variance	`rms.analytics.read`
Recommendations	`rms.recommendation.read` to read and generate, `rms.recommendation.manage` to accept or dismiss
Benchmarking	`rms.benchmark.read` to read, `rms.benchmark.manage` to define competitors and record rates

Permissions behind the Inventory screens#

Screen	Permission
Stores & Items	`inventory.catalog.read` to read, `inventory.catalog.write` to add or archive
Suppliers	`inventory.supplier.manage`
Purchase Orders	`inventory.po.read` to read, `inventory.po.write` to raise, send or cancel, `inventory.po.approve` to approve
Receiving	`inventory.receipt.write`
Invoices	`inventory.invoice.match`
Recipes	`inventory.recipe.manage`
Consumption	`inventory.consumption.write`
Stock Counts	`inventory.count.manage`
Valuation	`inventory.valuation.read`

Permissions behind the Billing screens#

Screen	Permission
Charge Codes	`billing.setup.read` to read, `billing.setup.manage` to edit
Article Groups	`billing.setup.read` to read, `billing.setup.manage` to edit
Tax & Service	`billing.setup.read` to read, `billing.setup.manage` to change a rate
Instructions	`billing.setup.read` to read, `billing.setup.manage` to define a template, `frontdesk.folio.transfer` to apply one to a group

See Charge codes, tax and billing setup for what each tab holds.

Permissions behind the Headquarter screens#

Screen	Permission
Dashboard	`headquarter.read`
Groups — the owner side (create a group, invite a property, revoke)	`headquarter.group.manage`
Groups — the member side (accept or decline your own invitation)	`headquarter.member.manage` on the hotel you pick

All three are anchored on org.manage in the default bundles, so only Owner reaches Headquarter out of the box — see the note above.

Permissions behind the Settings screens#

Screen	Permission
Team → People	`org.members.invite` to see and invite, `org.members.manage` to assign or remove roles
Team → Departments	`org.members.manage` to add, rename, deactivate or assign a department
Roles	`org.roles.manage`
Hotel	`hotel.settings.manage`; creating a property also needs `hotel.create`
Outlets	`pos.catalog.read` to read, `pos.outlet.manage` to edit the profile
Reference Data	`reference.manage`
Terminology	`hotel.terminology.manage`
Organisation	`org.manage`
Operator Links	`org.manage`
Delegation Roster	`org.manage`
Audit Log	`org.audit.read`
Notifications	`core.notifications.manage`
Escalation	`core.stepup.manage`
Data Import	`core.import.read` to see, `core.import.upload` to upload, `core.import.commit` to commit

Catatan
App installation is not on this list because it is not a Settings screen — apps.manage lives at Integrations → App Directory. See Installing and enabling apps for a property.