Architecting RBAC and ABAC for Multi-Tenant Hospitality

When Kushal began building the Workwise hospitality platform, the permission requirements were more complex than a standard role-based system could handle. A user might be a technical evaluator for Hotel A, Department B, but must have zero access to Hotel C's procurement workflows, even if they hold the same role title there.

He designed a combined RBAC and ABAC system where every role carries not just a permission set but a set of attributes that scope that permission to a specific business unit, department, and context. A role of technical evaluator is not a global identity; it is a scoped assignment.

The key architectural decision was to evaluate permissions at runtime against the approval instance's business unit context. When an approval workflow is triggered, the system does not look up a static list of approvers. It evaluates which users hold the relevant role and then filters that set by whether their role's attribute scope matches the business unit in question.

This made cross-tenant contamination structurally impossible. A user scoped to Hotel A cannot be surfaced in Hotel B's approval chain through any normal system path. The isolation is enforced by the data model, not by application-layer checks that could be misconfigured.

Kushal also built the authentication and authorization layer on top of this, ensuring that users interact with the platform without needing to reason about what they can and cannot access. The goal was a system simple enough that users could not make permission-related mistakes.