Plan Selection and Deactivation

Add-ons rarely stand alone. One requires a particular base plan; two others cannot be bought together. You express these relationships as product set dependencies, and the journey renderer uses them to enable, disable, and explain each option as the customer builds their order.

The two relationships

Within a product set, an item can declare a dependency on another item:

• Requires — this item is only selectable when its target is chosen, either as the selected base plan or as another selected add-on.

• Excluded by — this item becomes unselectable when its target is selected. Exclusion works in both directions: selecting either side locks out the other.

There is also a co-term with relationship available in the catalog. It records intent for reporting and future use but does not currently drive selection behaviour, so do not rely on it to constrain what a customer can pick.

What the customer sees

An option that fails its dependency check is not hidden — it is disabled and annotated with the reason. That is deliberate: showing an unavailable add-on greyed out with "requires Professional plan" teaches the customer what to do, where silently removing it just looks like the add-on doesn't exist.

Selections also deactivate themselves. If a customer picks an add-on and then changes their base plan so that add-on is no longer valid, it is automatically deselected rather than left in the cart in an invalid state.

Item classification

Every item in a product set is classified as base, addon, or optional. Classification determines how the item is presented — base plans as the primary choice, add-ons as supplementary selections — and dependency checks run against the current base and the set of selected add-ons.

Gotchas

• These are merchandising constraints, not security controls. Requires and excluded-by are evaluated in the journey interface to guide selection. They are not re-checked when the order is submitted, so treat them as a way to help customers build a valid order — not as authoritative enforcement. Anything that must hold no matter how the order arrives belongs in the Policy Engine or a blocking Business Rule, both of which run server-side.

• Dependencies are scoped to a product set. An item can only depend on another item in the same set. Cross-set relationships are not expressible.

• Exclusion is symmetric even if you only author one side, so you do not need a matching pair of rules.

Related

• Hide plans based on existing subscription products — controlling which items appear at all.

• Automated product removal — the deactivation behaviour in more detail.