Coordinate people & guests
Your staff see their work — not your revenue
Build your own roles from the module list. A housekeeper gets the room board and nothing else.
The reason most small hotels never give staff a login is not cost. It is that the software has one kind of user, so handing a housekeeper an account means handing them your revenue, your payroll and your guests' details.
So the owner keeps the only login, everything routes through them, and the system stops being used the moment they are away for a day.
Staff access & roles is one of the modules included in the MangoHost platform — every plan has all of them, so nothing on this page is an upsell.
The workflow
How it works
Roles you define, not roles we guessed
A role is a name and a set of modules. Create as many as your property needs — Housekeeping, Front Desk, Kitchen, Night Duty — and grant each one exactly the screens that job touches.
Anyone without a custom role gets a sensible default: the operational screens and none of the money ones.
Finer than a module, where it matters
The Restaurant module can be granted screen by screen, because a waiter and a cook need one screen each and nothing else. A kitchen display hangs on a wall for the whole service — putting the recipe book and the till behind it would mean anyone walking past can read both.
So a cook gets the kitchen queue. A waiter gets Orders. Neither gets the menu prices.
The money screens are not on the list
Billing, team management, integrations and hotel settings are deliberately not modules. They cannot be granted to a custom role at all, which means they cannot be handed out by accident.
Analytics, pricing, expenses and payroll are modules — so they can be granted, but only on purpose.
And a record of what everyone did
Every create, update and delete is written to an audit log with the actor, the entity and the time, along with every login, logout and impersonation. Not for the screens where it was convenient — for the platform.
Combined with roles, that is what makes staff logins safe to hand out: limited reach, and a record.
Two-step login, so a shared password is not a shared account
Every login is a password plus a six-digit code emailed to that person's own address. The code expires in ten minutes and dies after five wrong attempts, and only a hash of it is ever stored.
The practical effect is that an account cannot quietly become communal. If someone leaves and the password went around the office with them, they still cannot get in — the code goes to an inbox you control.
Passwords, stored properly
scrypt, with a random salt per password and a sixty-four byte derived key, compared in constant time. Plaintext is never written anywhere, including the logs.
It is worth being specific about this rather than saying "bank-grade", because the phrase means nothing and the parameters mean something. If you want the rest of them, they are on the security page.
In detail
| Custom roles | Name plus a set of granted modules, created per hotel. |
|---|---|
| Per-screen restaurant access | Orders, kitchen queue, menu, recipe book and tables granted individually. |
| Default staff access | Operational screens only, for anyone without a custom role. |
| Admin concerns excluded | Billing, team, integrations and settings cannot be granted. |
| Audit log | Every CUD action plus auth events, with actor, entity, id and timestamp. |
| Login rate limiting | Five failures per email in 15 minutes. |
| Two-step login | Password plus a six-digit emailed code. |
| Per-hotel access | In a multi-hotel account, access is granted per property. |
Who this is for
You are the only person with a login
That is the bottleneck this removes, and it is usually the thing stopping the software from being used at all.
You have staff turnover
A role is a set you reuse, not a checklist you rebuild for each new hire.
See it on your own property
Thirty minutes with the IslandLink team, your rooms and your rates. No card, nothing to sign.