SaaS entitlements define which capabilities a customer plan provides; permissions define what a particular user may do. Check both where they apply. A customer paying for a feature does not authorise every member to administer it, and a user role should not unlock a capability outside the current entitlement rules.
Let’s plan your SaaS capability model.
Bring your workflow, constraints and open questions. We’ll help you define the requirements and work through a practical next step.
Define the capability catalogue
Use stable capability identifiers, limits and effective rules rather than embedding plan names throughout the code. Plans and commercial labels can change while the underlying capability remains the same.
For a hypothetical analytics product, an organisation may have export access while only approved roles may export sensitive reports. The interface should explain the actual limiting condition.
Build an entitlement and permission matrix
| Condition | Product response | Check to enforce |
|---|---|---|
| Plan lacks capability | Explain available scope accurately | Server entitlement check |
| User lacks authority | Appropriate access explanation | Role and record-level checks |
| Usage limit reached | State limit and permitted next step | Authoritative usage calculation |
| Plan changes | Defined effective transition | Existing jobs and records reviewed |
| Trial expires | Honest access state | Approved grace or restriction rules |
| Billing uncertain | Use the defined entitlement policy | Do not infer from a local payment screen |
Have commercial owners approve upgrade, downgrade and grace-period behaviour. This checklist does not determine billing obligations or contractual rights.
Handle existing work during a plan change
Decide what happens to scheduled exports, stored configuration and records created with a now-unavailable feature. Hiding the menu does not resolve those dependencies.
Show the effective plan and capability state with suitable freshness. A cached UI should not grant a server-side action after the entitlement changed.
Test across both dimensions
Use synthetic organisations on different plans and users with different roles. Attempt direct API actions as well as visible controls. Include a plan change while a job is pending.
Keep support diagnostics clear: feature unavailable, role restricted and usage exhausted need different remedies. Avoid sending every user to an upgrade page when the actual problem is permission.
Entitlement questions
Can plan names act as permission roles?
Keep the concepts distinct. Their change cycles, authority and scope differ.
Should downgrading delete feature-related data automatically?
Only under an explicit approved lifecycle and communication process. Loss of access and deletion are separate decisions.
Pair entitlements with subscription access states, and review the capability model with Drema's SaaS team.