Roles and permissions: one model across every module

What does the capability do?

It gives multi-site operators access control that matches their shape, enforced where it cannot be bypassed.

• A generated matrix. Permissions are the product of business areas and actions, and every combination becomes an authorisation policy at the API. There are no accidental gaps where a screen exists but no permission governs it.
• Scope-bound roles. A role grant attaches to a scope, and higher scopes cover everything beneath them: grant at organisation level and every site is covered; grant at site level and only that site is. Staff covering two sites get two explicit grants, not an over-broad promotion.
• Field-level masking. Sensitive fields are masked in the API handlers for roles without the specific permission, in an explicit masked form rather than a blank. See data protection for the full model.
• Approval as its own action. Approving is separate from editing, so workflows that need a second pair of eyes can require them by permission, not convention.
• Your identity provider, your policies. Sign-in supports a variety of methods and typically federates to Microsoft Entra ID or Google: seamless SSO for staff, with MFA and conditional access enforced by the identity platform you already govern.
• A tested catalogue. A single translatable catalogue defines what every permission unlocks, mirrored across the API and the admin in every language, with tests that fail the build when the catalogue and the code drift.

Why enforcement lives at the API

Permissions configured in a user interface are suggestions; permissions enforced in the API are controls. Because every policy check happens where the data is served, a misconfigured screen, a custom integration, or an exported report cannot leak what a role should not see. The same property is what makes the model safe to extend: new modules inherit the matrix rather than inventing their own rules.

Why it matters

Access control is where operational trust lives: front-desk staff should resolve queries without seeing bank details, site managers should run their site without browsing the estate, and finance should see everything with an audit trail behind them. One model, enforced at the API and federated to your identity platform, delivers that across booking, billing, membership, and the rest of the platform. Franchise networks get a deeper treatment of the same model in scoped permissions.