Glossary
Feature flags vs entitlements
Feature flags and entitlements both decide whether a piece of code runs, but they answer different questions. A feature flag answers whether a feature has been released to this user yet; an entitlement answers whether this customer's plan includes it, and follows what the customer pays for.
How it works
Two questions, asked separately
- Feature flags. Switches for releasing code: turn a feature on for some users, a share of users or one environment, then remove the flag once the release is done.
- Entitlements. Grants that follow the plan: they change when the customer subscribes, upgrades, downgrades or cancels, and last as long as the plan does.
- Where they meet. A paid feature still being rolled out has both: the flag says it is released to this user, the entitlement says their plan includes it.
Example
You release a new analytics page to one in ten users behind a flag, and it is a Pro feature. A Starter user in that group has the flag on but no entitlement, so the page shows an upgrade prompt. A Pro user outside the group has the entitlement but not the flag, so they do not see the page yet.
Compared
Terms next to it
- Entitlements
- The full definition: what a plan grants, and how much of each limit is left.
- Feature gating
- The check made against entitlements before a paid feature runs.
- Roles and permissions
- What a user may do inside an organization, such as admin or viewer. An entitlement is what the organization's plan allows, whoever the user is.
Building it yourself
What you handle if you keep both
- Decide which system owns each check. Release checks belong with flags, plan checks with entitlements; a check that mixes the two is hard to reason about.
- Keep plan rules out of flag targeting. If flags target users by plan, every plan change has to be copied into the flag rules.
- Make entitlements follow the subscription. Upgrades, downgrades and cancellations change them; nobody flips them by hand.
- Clean up flags, not entitlements. A flag is removed once its release is done; an entitlement stays as long as the plan.
In ShipRev
Where the entitlement side sits in ShipRev
ShipRev holds the entitlement side. Plans grant capabilities and are published as versions, and a ruling for a customer's organization is worked out from the same customer record that holds their subscription, so when the subscription changes, the ruling follows. Your backend asks the Server SDK for a ruling on the request path, and the ruling carries the remaining balance and says whether it is live or degraded.
EntitlementsIn the docs