Assigning Features to Tiers
A set links features to a tier. The mechanics are simple; the testing is what matters.
Where to find it
Architect Panel → Subscriptions:
- Feature Sets — the groupings features are sold in
- Subscription Packages — the packages customers buy
Architect Panel → Configuration:
- Multitenancy — the tenants a package applies to
Test each tier as a customer
Not as an administrator, and not by reading the configuration. Sign in to an account on that tier and use the product.
This is the step that catches the two failures that matter: something that should be available and is not, and something that should not be and is. The second is revenue you are giving away, and neither is visible from the configuration screen.
The lowest tier deserves the most testing
Because development happens with everything on, so the entry tier is the one most likely to be broken — and it has the most customers and the least tolerance.
Check every boundary
Where two tiers differ, exercise that difference in both directions. A feature that fails ungracefully when absent is worse than one that is simply missing.
Changing a tier affects live customers
Adding a feature is usually safe and welcome. Removing one is a takeaway and needs deciding deliberately — including what happens to data reachable only through it.
Where you must remove, grandfather existing customers.
Watch for tier drift
Features get added to tiers to close a specific deal, and over time the tiers stop matching the published comparison. That produces customers who believe they have something they do not, and a sales team quoting from a table that is no longer true.
Review what each tier actually contains against what you publish, periodically.
One-off exceptions are debt
Granting one customer a feature outside their tier is easy and accumulates. Each is invisible, unreviewed, and will surprise somebody at renewal. If you do it, record it and revisit it.
Keep the published comparison honest
The comparison table is what customers buy from. If it says something a tier does not deliver, that is a dispute waiting to happen — and the customer's reading is the one that will be held to.
Worked example
A team tests all three tiers as real customer accounts before each release, entry tier first. A quarterly check compares actual tier contents against the published table, which found two features quietly granted to a middle-tier customer during a deal and never recorded — now documented as a deliberate exception with a renewal date.
Recommendations
- Test each tier as a customer, entry tier first.
- Exercise every boundary in both directions.
- Record one-off exceptions and revisit them.
- Reconcile tiers against the published table.