The platform Live

The hotel ID, and who may see what

Sign-in is a hotel ID, an email and a password; row-level security in the database decides what that login may see; a platform user sees nothing until a hotel has let them in.

The first thing a person types is which hotel they belong to. The second and third are who they are. Everything after that is decided in the database, not in the application: a policy on every table says which rows this login may read and which it may write, and a query that forgets to filter still cannot see across the line.

Default deny

A login has access to no hotel until it has been given one. A hotel added to a group is invisible to every existing login until an administrator says otherwise. The rule is written as a policy, tested by a suite that signs in as the application role, and it has caught two regressions before they shipped.

A group

A group is an account with many hotels. A group login sees the hotels it was given; the owner sees all of them; the central desk, the CRM and the heatmap read as many rows as the login may.

The platform is outside

A platform user — our support — stands outside every account and sees nothing inside one. Entering an account is a grant the account gives, time-boxed, logged, and visible to the account afterwards.

More on The platform

One database, not five that talk to each otherEvery integration between two systems is a place where a guest becomes two guests and a bill becomes two bills. The way not to have that problem is not to have two systems. Roles and capabilitiesFront desk, housekeeping, back office, manager, administrator — and under each role a catalogue of capabilities that reach down to the button, gated by the module the account has bought. A group of hotelsOne hotel or twenty, on one account: each with its own business date, rates and rooms; the group with one guest list, one central desk, one heatmap and one set of consolidated numbers. Support access is granted, time-boxed and loggedOur own people cannot open a customer's hotel. The account lets them in for a window, the session is logged, and the account can see afterwards who was inside and when. The manual ships with every screenA hundred and twenty-four pages, written for the person at the desk, filtered by module and role, opened with one key on any screen — and published free at pms.theorionhotels.com/help. When the system refusesEvery refusal is a sentence written for the person at the desk, in the manual, findable by pasting it in — and the rule for what gets refused is one line. The log is the priceEvery change to every record carries who, when, from which login, which address and which machine — and the log is read on one page, by support and by the hotel. Opening a hotelThe wizard takes the code, the GSTIN, the room types with real room numbers and a rate each; readiness says what is still missing; the board tracks it to open — and the hotel opens itself. Modules and the subscriptionEach module is licensed on its own, switched per account by the platform, and the switch has teeth — a suspended account cannot sign in. EmailConfirmations, invoices, payment links, the morning sheet, scheduled reports — sent in the hotel's name, replies routed to a person, every send on the log. SecurityRow-level security in the database, credentials in an encrypted vault, host-only sessions per door, SSH guarded by fail2ban, backups before every migration, and a test suite that signs in as the application role.