Decision guide
Entitlements and user permissions solve different questions.
Acme can buy Advanced Reporting while only its Analysts and Admins may run it. The entitlement says the account has the feature. Authorization decides which users can use it.
By Jasen Fici · Updated August 22, 2026
Two decisions
The account needs the feature. The user needs permission.
Entitlements answer whether Acme has Advanced Reporting. Authorization answers whether Jules may run a report for Acme. Both checks must pass before the action runs.
What each system owns
Use entitlements for customer access and authorization for user actions.
This table separates the subject, inputs, exceptions, and audit reason for each decision. Plan, purchase, contract, and customer override changes belong in entitlements. User, role, policy, and resource changes belong in authorization.
| Dimension | Entitlements | Authorization / RBAC |
|---|---|---|
| Subject | Customer, account, or subscription | User, service identity, or principal |
| Question | Was this feature or value bought, assigned, or granted? | May this principal perform this action on this resource? |
| Input | Plan, package, purchase, contract, dates, override | Role, policy, relationship, ownership, resource context |
| Example | Acme has Advanced Reporting and a 40-seat limit. | Jules is an Analyst who may run reports but cannot manage billing. |
| Exception | Customer-specific subscription feature override | User role change or policy exception |
| Audit reason | Why the account received product access | Why this user could perform this action |
Check both
Keep the two answers explicit.
Application code already has the authenticated user and account. Subscrio checks whether the account has the feature. Your authorization system checks whether the user's role permits the report action.
Return a product-access response when the account lacks the entitlement. Return a permission response when the account is entitled but the user is not authorized.
const accountHasFeature = await subscrio.featureChecker.isEnabledForCustomer(
account.key, 'analytics', 'advanced-reporting'
);
if (!accountHasFeature) {
throw featureNotIncluded();
}
const userMayRun = authorization.can(user, 'report:run', account);
if (!userMayRun) throw forbidden();Where changes belong
Update the system responsible for each type of access.
Changes to a customer's plan, purchase, or contract belong in the entitlement data. User, role, and resource changes belong in authorization. Keeping them separate makes each decision easier to explain and audit.
Entitlement changes
- Acme upgrades to a package with Advanced Reporting.
- Sales grants Acme a 40-seat override.
- The package expires at the end of the contract.
- A purchased module adds export capability.
Authorization changes
- Jules becomes an Analyst.
- An Admin removes report access from a role.
- A resource owner grants a user access to one workspace.
- A service account receives a narrower policy.
Review the entitlement data model and resolution order before combining the result with your authorization check.
Common questions
Questions about entitlements, authorization, and RBAC
What is the difference between entitlements and authorization or RBAC?
Entitlements determine whether a customer or account has a product feature. Authorization and RBAC determine whether the current user may perform an action with that feature. Many protected actions require both checks.
Which decision should run first?
Both must pass. Checking the account entitlement first can avoid unnecessary authorization work for an unavailable product feature, while checking basic authentication first is usually necessary to identify the user and account.
Is a customer override a permission?
No. A customer override changes an entitlement value for the account or subscription. It does not grant a user role or permission inside that account.
Where should the combined check be enforced?
Check both in the code that performs the protected action. The interface can use the same result for explanation, but it should not be the only check.
Next step
Require the account grant and the user permission.
Keep both facts visible in logs and denied responses so support and security teams can explain the result.