Automated Product Removal

"Remove this product automatically when X happens" covers two very different requirements, and PeakCommerce handles them differently. One is well supported. The other is not, and it is better to know that up front than to design around a capability that isn't there.

Removing a selection from an in-progress order

This works, and it is automatic. While a customer is building an order, the journey continuously re-checks every selected add-on against the product set dependencies. When a selection stops being valid — because the customer changed base plan, or picked something that excludes it — the add-on is deselected for them rather than left in the cart in a broken state.

You do not configure this behaviour directly. You author the requires and excluded by relationships between items in a product set, and the deselection follows. See Plan selection and deactivation for how to define those relationships.

Removing a product from a live subscription

This is the requirement that is not currently supported, and it is worth being precise about why, because part of the configuration surface implies otherwise.

Business Rules include a dependency behaviour setting with values like cancel with base, convert to standalone, and require decision. These describe what should happen to a dependent add-on when its base subscription is cancelled. The setting is stored and returned in previews, but no code path acts on it — nothing is cancelled, converted, or queued for a decision as a result of choosing a value.

Similarly, the co-term with dependency type can be set on product set items but currently has no runtime consumer.

So there is no rule today that says "when the customer cancels the base plan, automatically cancel the attached add-on". Do not rely on dependency behaviour to produce that outcome.

Handling it in the meantime

Until this is implemented, the workable approaches are:

• Make the removal explicit in the flow. A cancellation journey can present the dependent add-ons and have the customer or CSR confirm what happens to each, then commit those changes as part of the same order.

• Block the change instead. A Business Rule scoped to the cancellation direction can mark the change as blocked, forcing the customer down a path that handles the dependants properly.

• Reconcile after the fact, using the Agent API to find subscriptions with orphaned add-ons and act on them deliberately.

Related

• Plan selection and deactivation — the dependency relationships that drive in-cart deselection.

• Raise an error — stopping a flow with an explanation.

• Logic & Rules overview — which engine owns which job.