Plans, packages and permission tiers

Three screens sit next to each other under Catalog and are easily confused.

• An edition is the subscription plan — what a tenant is on. Tier, price, and the entitlement map: capacity caps, module switches and capability flags.
• A package is a line item in the billing catalogue — what a tenant buys on top. An extra warehouse, a support pack, a bundle of credits. It grants no entitlements.
• A vertical is the industry a tenant operates in. Read-only here, switched on per tenant.

In one line: the edition says what a tenant can do, packages say what else they bought, verticals say what industry they are in.

Editions

Creating a plan

1. Go to Catalog → Editions and click New edition.
2. Enter the Name (key). This is the identifier, and it is permanent.
3. Enter the Display name, choose the Tier (Basic, Standard, Growth, Professional or Enterprise) and add a Description.
4. Leave Active ticked so it can be subscribed to.
5. Under Pricing, set Monthly price, Annual price, Setup fee, Trial days and Monthly credits, and tick Allow setup-fee installments if the setup fee can be spread.
6. Under Entitlements, work through the three groups:
   • License & limits — numeric caps. Leave a box blank for unlimited.
   • Modules — on or off.
   • Capabilities — on or off, or a dropdown. Anything you do not touch keeps the platform default.
7. Click Create edition.
8. Check the read-only Feature snapshot card. That is exactly what a tenant receives when the plan is provisioned.

Typing an existing key into the New edition form overwrites that plan

Creating an edition is an upsert keyed on the name. There is no “already exists” error and no warning — if you type the key of a live plan, you have just replaced it.

Check the Editions list for the key before you create anything.

Anyone who can see Editions can delete them

The permission catalogue deliberately defines no create or delete permission for editions — the intent was that they are seeded and never user-managed. The console offers New edition and Delete anyway, and because the authorization layer falls back to the resource’s default permission when a specific one is undefined, both need only the view-level permission.

In practice: give provider.editions only to operators you would trust to delete a plan. The manage_features permission is declared but never actually consulted.

Changing a plan later

Reopen the edition, change the controls, Save changes. Name (key) stays locked.

Existing tenants are not retro-fitted. They keep the entitlements they were provisioned with until somebody reprovisions them. The delete warning says as much: “Tenants on it keep their provisioned features until reprovisioned.”

The Editions list has no filters and no search, and inactive editions are mixed in with active ones.

Packages

1. Go to Catalog → Packages and click New package.
2. Enter the Name.
3. Choose the Kind — subscription, license add-on, credit pack or service pack. This narrows the next box.
4. Choose the Type, the Unit and the Status.
5. Enter the Amount.
6. For a credit pack, enter Credits per pack.
7. Optionally add an Image URL and a Description, and tick Recurring charge for a per-period charge.
8. Click Create package.

On an existing package, Resolve price lets you paste a tenant’s identifier and see whether a negotiated override applies, or the list price if not.

A package of kind “subscription” is not a plan

It is a billing-catalogue stand-in so a plan can appear on an invoice. To change what a plan grants, always edit the Edition, never the package.

Verticals

Catalog → Verticals is a read-only list of the industries registered on the platform. You cannot add, edit or remove one here — the list comes from the software itself.

Turning a vertical on for a particular customer is done on that tenant’s page, subject to the plan’s vertical-count cap.

Permission tiers

Platform → Permission tiers is the plan-to-permission matrix: which subscription tier a permission requires before it works, and optionally which module must also be enabled.

This is the runtime-editable version of what would otherwise be hard-coded, so re-tiering a permission needs no new release.

Re-tiering a permission

1. Go to Platform → Permission tiers.
2. Find the permission with the Search box, or narrow with the Category pills.
3. Click the pencil.
4. Change the Minimum tier — Any (ungated), Basic, Standard, Growth, Professional or Enterprise.
5. Optionally set a Required module / vertical so the permission also needs that feature switched on.
6. Add a Note explaining why.
7. Click Save.

To open a permission up to every plan, either set the tier to Any (ungated) or delete the row.

This is the most dangerous edit in the console, and it has no confirmation

A saved change takes effect immediately, across every tenant on the platform. The cached matrix is refreshed and every tenant’s permission snapshot is thrown away on the spot.

Raise the tier on a widely-held permission and every tenant below that tier loses it at once — mid-shift, with no warning to them and no “N tenants affected” preview for you.

Only Delete warns you at all, and only about the opposite risk: “This permission will become ungated (available on every plan). Applies to all tenants immediately.”

Make tier changes deliberately, out of hours, and check a tenant on the affected plan straight afterwards.

On an existing gate the Permission prefix is locked. To point a gate at a different permission, delete it and create a new one.

Related

• Tenants
• Billing and invoices
• The host console