Features, Entitlements, and Permissions
Dineax keeps commercial packaging, tenant access, and user access separate.
Key Definitions
| Concept | Meaning | Example |
|---|---|---|
| Application module | Technical or RBAC grouping inside the product. | Inventory screens grouped for permissions. |
| Commercial module | Customer-facing package that may be included in a plan or sold separately. | Advanced Reporting as a future package. |
| Canonical feature | Stable product capability used for entitlement and enforcement. | WhatsApp notifications or KDS station limit. |
| Entitlement | Tenant-level right to use a capability. | Tenant can use a communication capability. |
| Permission | User-level right to perform an action. | Manager can manage staff access. |
| Feature flag | Release-control mechanism. | Feature available only during rollout. |
| Operating model | Outlet workflow applicability. | Table service or counter service. |
Navigation is not authorization
Navigation visibility is not authorization. Backend authorization and approved entitlement enforcement remain authoritative.
How They Work Together
A tenant may be entitled to a capability, but a specific user still needs the right permission to perform an action. Conversely, a user permission does not mean the tenant has purchased or enabled a future commercial module.
Example
An outlet manager may have permission to view reports. If advanced reporting is later sold as a commercial module, Dineax must also check whether the tenant is entitled to advanced reporting. Until backend enforcement is applied, permission visibility alone should not be described as commercial access control.