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.