Admin & Access Console · Documentation
Business Problem & Solution
The problem Admin & Access Console solves in the hospitality ecosystem and how this downscaled demo proves it.
← Admin & Access ConsoleOne place to answer 'who can do what'
An ecosystem of 44 coupled apps shares one access model: the same sign-in gate, the same owner/viewer distinction, the same per-credential scope. Someone has to administer that — provision staff, set roles, scope access to domains and apps, and see who is currently signed in — and it cannot be scattered across every app's settings.
Admin & Access Console is that single cockpit. It administers the foundation's existing auth and session machinery rather than forking its own, so the access it manages is exactly the access every other app enforces.
What this demo proves — and what it simplifies
It proves the gated-content invariant end-to-end: the whole console is owner-only, and for a non-owner the content is not merely hidden, it is absent from the DOM — a gate renders instead. It proves role administration is a real, audited action: cycling a role or suspending a user emits an event and lands in the audit trail.
It simplifies the identity provider. The prototype uses the universal owner credential with no 2FA; a real SAML/OIDC IdP is labelled as Stage-2 wiring. Sessions are synthetic, and user emails are all @synthetic.example.
Reality contract
Synthetic staff only — about two dozen invented users across owner/operator/analyst/viewer roles, with synthetic devices and IPs for sessions. No real people, no PII, no real credentials. Figures are representative and labelled.