Match Quantity Across Plans

When two charges have to move together — a platform fee that must always match the seat count, or an included-usage allowance that scales with licences — you express that with a plan dependency. This is the engine built for quantity mirroring, and it is the only one that does it.

Why it matters

Quantity relationships are easy to state and painful to enforce by hand. If a customer buys 40 seats, the companion charge has to be 40 too — in the storefront, in a CSR-assisted change, and in anything driven through the Agent API. Encoding the relationship once in the catalog means every surface honours it, and nobody has to remember to update the second line.

How a dependency is defined

A dependency has a source — a product, plan, and charge, plus the field being watched — and one or more targets, each naming its own product, plan, charge, and field. Both the source field and each target field are either quantity or included units.

The transform decides what the target becomes:

• Identity — the target takes the source value exactly. 40 seats produces 40.

• Ratio — the target is the source scaled by a positive factor. A factor of 0.5 turns 40 seats into 20; a factor of 100 turns 40 into 4,000 included units.

The mode decides which way it flows. One-way pushes source to targets only. Bidirectional also propagates a change made on a target back to the source, applying the inverse of the transform.

Activation scope controls whether a target that is not in the cart gets pulled in. Leave it at always to apply the dependency unconditionally, or choose when target present to update the target only if the customer already has it.

Where it applies

Dependencies resolve when a cart is built and when a subscription quantity is changed, so the same relationship holds for self-service checkout, CSR-driven changes, and API-driven orders.

Gotchas

• Chains resolve, but not infinitely. A dependency whose target is itself a source will keep propagating, up to a depth of eight links. Deeper chains stop there.

• Cycles are rejected at save time, along with self-links, duplicate targets, references to a charge that does not exist, and bidirectional links that contradict each other. You cannot save a dependency that would loop.

• Ratio factors must be positive. Zero or a negative factor is rejected.

• Rounding is the transform's business. A ratio that does not divide evenly produces a fractional result; check the outcome for factors like 0.3 before relying on them.

Related

• Plan selection and deactivation — constrain which add-ons can be chosen, rather than how many.

• Enforce product quantity — cap the total units on an order.