The Subscription Engine

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.

Subscription Limits

A limit caps how many subscriptions one customer may hold.

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 limit

What it protects against

• Accidental duplication — somebody subscribing twice because the first attempt appeared to fail. This is the common case.
• Automated abuse on a self-service signup.
• Unbounded provisioning, where each subscription consumes real resources.

The duplicate is the realistic problem

Not fraud. A customer whose payment page was slow, who pressed the button again, and now has two subscriptions and two invoices — that is a support conversation, a refund and an apology, and it happens regularly on any self-service flow.

A limit turns it into a message at the point of the second attempt.

Choose a number that fits your model

• One — where a customer is genuinely one subscription. Cleanest, and prevents duplicates outright.
• A few — where somebody legitimately runs several, such as a group with separate entities.
• Unlimited — only where you have a specific reason and something else guards against duplication.

The message matters as much as the limit

A customer hitting it must understand why and what to do. "You already have a subscription — here it is" is helpful. A generic refusal reads as a fault, and they will either contact you or leave.

Where the cause is usually a duplicate attempt, saying so directly resolves most of them without anybody being involved.

Have a path for the legitimate case

Somebody will genuinely need more. Make sure that is possible — an administrator raising it, or a documented process — rather than a wall with nothing behind it.

Set it before self-service opens

Retrofitting a limit onto customers who already exceed it means deciding what to do about them. Setting it first avoids that.

Watch how often it is hit

Frequently, and either it is too low or your signup flow is producing duplicate attempts — which is worth fixing at source. Never, and it is doing no harm, so leave it.

Worked example

A product limits customers to one subscription, with a message linking to the existing one. Hits are logged and reviewed: an early spike traced to a slow payment confirmation that made customers press again, which was fixed. The limit still catches a handful a month.

Recommendations

• Set a limit before self-service opens.
• Write a message that explains, not a refusal.
• Provide a route for the legitimate case.
• Treat frequent hits as a signal about your signup flow.