Linking to a Tenant

A package applies to a tenant. That link is what turns a commercial arrangement into what the software actually does.

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 themselves

This is the join that must be right

Everything else is configuration; this is what connects it to a paying customer. A wrong link means somebody has the wrong features — either more than they are paying for, or less.

Neither is discovered quickly. Too much is silent; too little is reported as a fault rather than as a billing question.

One package per tenant

Keep it unambiguous. If a tenant appears to have two, entitlement depends on how that is resolved, which is exactly the kind of thing nobody wants to reason about during a support call.

Check it at the start of the relationship

When a customer is onboarded, confirm their tenant is on the package they bought — by signing in and looking, not by reading the record. Getting this wrong at the start means the whole relationship is on the wrong footing.

When entitlement looks wrong

Work through it in order:

Which package is the tenant actually linked to?
Which feature set does that package grant?
Does that set contain the feature?
Is the user's permission the problem rather than the feature?

The fourth catches a good proportion. A customer whose tier includes something, whose staff cannot use it, has a permissions question rather than a subscription one — and support will otherwise escalate it as billing.

Changes need to take effect predictably

When a customer upgrades, they expect the feature promptly. Know how quickly a change applies and whether anybody needs to sign out — and tell the customer, rather than leaving them refreshing.

Reconcile periodically

Compare tenants against packages against billing. Divergence is money, and it accumulates quietly through trials that were extended, deals with exceptions, and migrations that missed one.

Record exceptions where they exist

If a tenant is deliberately on non-standard terms, that should be recorded against them rather than living in somebody's memory. Undocumented exceptions surface at renewal, usually in front of the customer.

Worked example

An onboarding checklist includes confirming the tenant's package by signing in as a customer user. A monthly reconciliation compares tenants, packages and billing — which found one tenant left on a trial package eight months after converting, and one deliberate exception now recorded with its renewal date.

Recommendations

Confirm the link at onboarding, by looking.
One package per tenant.
Check permissions before concluding it is a subscription problem.
Reconcile monthly — divergence is money.