Loading

Enabling the Engine

The subscription engine ships disabled. Enabling it makes packages, feature sets and limits actually take effect.

Where to find it

Architect Panel → Subscriptions:

  • Feature Sets — the groupings features are sold in
  • Subscription Packages — the packages customers buy

Architect Panel → Configuration:

  • Site Settings — the subscription engine settings

Architect Panel → Commercial:

  • Carts — payment

Have this in place first

  1. Features defined, and their off behaviour decided.
  2. Feature sets assembled into tiers.
  3. Packages created and named.
  4. Tenants linked to packages.
  5. Every tier tested as a real customer.

Enabling before the linking is done means customers land on whatever the default is, which is rarely what anybody intended.

Test the unentitled state hardest

Development happens with everything available, so the state that ships broken is the one where a feature is absent. That state is seen only by customers who did not pay for it — who are also the least likely to be given the benefit of the doubt.

Sign in as a customer on the lowest tier and use the product properly.

Unavailable must not look broken

A feature that is absent should be absent, or clearly explained with a route to upgrade. What it must never do is fail when used — that reads as unreliable software rather than as a commercial boundary, and it damages trust in everything else.

Decide the default for a tenant with no package

There will be one — a new tenant, a migration, a mistake. Whatever they get by default should be safe: minimal rather than everything, because the failure mode of the alternative is giving away the product.

Know how to turn it off

If enabling causes widespread problems, you want to reverse it quickly. Confirm that path works before you need it, and make sure somebody other than you knows it.

Tell your support team first

They will receive the calls. Being able to say "that feature is not in your package, here is how to upgrade" is a very different conversation from investigating a suspected fault, and the difference is whether they were told.

Watch the first days

Check for customers reporting missing features and for anybody reaching something they should not. Both appear immediately if they are going to.

Worked example

An organisation completes its packages and tenant links, tests all three tiers as customer accounts with the entry tier tested most, briefs support, then enables the engine on a Tuesday morning. Two customers report a missing feature in the first day — both correctly, both resolved as upgrade conversations rather than faults.

Recommendations

  • Link every tenant before enabling.
  • Test the lowest tier hardest.
  • Default an unlinked tenant to minimal.
  • Brief support before you switch it on.