Subscription group modeling
Subscription groups define packaging constraints for self-serve offers.
They answer "what combinations are valid", "how transitions work", and "how the effective plan is derived".
Model choices
| Pattern | Meaning | Typical use |
|---|---|---|
| exclusive tier group | customer chooses one tier from many | base plans (starter/pro/business) |
| additive add-on group | add-ons can coexist with base tier | capacity packs, premium modules |
| conditional add-on group | add-on requires specific base tiers | enterprise-only modules |
Structural constraints
- Recurring prices must define a subscription group.
- When recurring cadence is configured, group identity should be explicit and stable.
- A single provider subscription should not span multiple subscription groups.
- For non-stackable groups, an account can hold only one active/trialing subscription at a time.
Transition rules to define explicitly
- upgrade timing
- downgrade timing
- cancellation timing
- mid-cycle proration/credit policy
Governance guidance
- Keep compatibility matrices versioned and auditable.
- Treat group-rule changes as migration events, not silent config edits.
- Validate purchase intent against group rules on backend, not only UI.
Verify
- Invalid combinations are blocked consistently across UI and backend.
- Transition outcomes are deterministic for overlapping requests.
- Support can explain effective subscription state from group rules plus event history.
Next
- Runtime behavior: Access activation
- Lifecycle transitions: Plan changes