How QCMM Decides Whether a Plan Change Is Available

QCMM does not infer that every higher-priced Plan is a valid upgrade. A customer sees only Plan changes that satisfy the current membership state and an administrator-defined, published change path.

A Published Path Must Exist

The current Plan and destination Plan must be different, and QCMM must find a published Plan upgrade/change path connecting them. The destination Plan must also be available under the path and current site configuration.

The Customer Must Be Eligible for the Path

Each path can carry Joomla user-group restrictions. QCMM evaluates those restrictions for the signed-in user before presenting or accepting the path. A path that exists in Administrator can therefore be hidden from a customer who does not meet its allowed-group rules.

Membership State Still Matters

The self-service change action accepts only supported current states, including Active and Pending Payment. Expired, cancelled, or otherwise ineligible records are not treated as interchangeable with a current membership.

Configured Does Not Always Mean Immediate

Paths requiring administrator approval or configured with deferred/placeholder behaviors are recognized but are not executed as an immediate self-service change. QCMM directs the customer to administrator handling instead.

QuantaCade Product Integrations Can Add Their Own Guardrails

Where QCMM is used to sell QuantaCade product tiers, product-family and All Access logic can suppress a redundant individual-product change. Treat those integration rules as an additional eligibility layer, not as a replacement for the QCMM path itself.

Community Discussion

Want to compare membership workflows or share practical QCMM tips? Visit the QC Memberships & Meetings Community. For private support, account-specific billing or entitlement issues, or feature requests, use the QuantaCade support system.