Use conditional logic for Product Add-On fields

Conditional logic changes whether one Product Add-On field is visible or available according to values entered in other fields in the same group or product-local definition. Use it to reveal follow-up questions, enable a priced upgrade only after an eligible selection, or hide fields that do not apply.

Before you begin

• Create the source and target fields in the same Product Add-On group or product-local definition.
• Give choice options clear labels so the rule editor is easy to review.
• Save a draft and use the impact preview before publishing a change to a shared group.
• A condition cannot read a field from another group. This keeps each definition portable and its evaluation cost bounded.

Create a rule

1. Open Products → Product Add-Ons → Groups and edit a group, or edit a product and open Product data → Add-Ons.
2. Open the field that should change and locate Conditional logic.
3. Select Enable conditional logic.
4. Choose an Effect:
   • Show when rules match hides the target until the rules match.
   • Hide when rules match hides the target while the rules match.
   • Enable when rules match keeps the target visible but unavailable until the rules match.
   • Disable when rules match keeps the target visible but makes it unavailable while the rules match.
5. Choose whether All rules must match (AND) or Any rule may match (OR).
6. Select Add rule, then choose the source field, operator, and expected value. Choice fields show their option labels while storing stable identities.
7. Choose the Inactive value policy. Preserve retains the browser value so it can return during the current form session; Clear removes it as soon as the field becomes inactive.
8. Save the draft, review the impact, and publish it when ready.

The editor rejects self-references, references to headings, missing fields or options, circular dependencies, and chains that exceed the supported depth. If a referenced field or option was removed, the editor marks the broken reference instead of silently linking another item with the same label.

Understand inactive values

An inactive field is never required, never adds a price, and is not stored in the cart or order snapshot. This server rule applies even if a visitor changes the page's JavaScript or submits the inactive field manually.

The Preserve policy only controls the current browser form. It is useful when a shopper briefly changes an earlier answer and then restores it. It does not persist the inactive value to WooCommerce. Clear is preferable when retaining the previous browser value could confuse the shopper.

Existing orders keep their immutable historical snapshots until an authorized user explicitly edits the line. Editing or repeating a purchase uses the current published definition and reevaluates its conditions.

Operators and values

The rule editor supports explicit comparisons only; it does not execute formulas or custom code.

File fields support only Is empty and Is not empty. Headings can be shown or hidden but cannot be enabled, disabled, or used as a source.

Limits and performance

Each field accepts up to 10 rules, each definition accepts up to 100 rules, and a dependency chain can be up to 8 levels deep by default. The public operational-limits filter can lower or raise these values within fixed safety ceilings. POM compiles the definition into a topological evaluation order when the public model is prepared, then reevaluates only that definition; it does not search products, groups, or the catalog while a shopper changes a value.

The POM product REST response and WooCommerce Store API Product Add-Ons extension expose schema version 2. Every field contains its versioned condition, and every context contains conditional_logic.evaluation_order, dependents, max_depth, and rule_count. Headless clients can therefore reproduce the same deterministic interface, but the server remains authoritative for validation and pricing.

Verify the result

1. Test a non-matching and matching value on a simple product.
2. Confirm a hidden required field does not block Add to cart.
3. Confirm an active required field does block Add to cart until completed.
4. Put a price on the target field and verify it appears only while the target is active.
5. Repeat with a variation and in a Cart or Checkout Block flow.
6. Change language and confirm translated labels change while the rule still follows the same field and option identities.
7. If order-line editing is used, open WooCommerce → Orders, edit the add-ons, and confirm the same fields become visible or unavailable.

Troubleshooting

• If saving reports a dependency cycle, remove one rule from the circular chain. Reordering fields does not remove a cycle.
• If a rule reports a missing reference, select an existing field or option. POM never relinks by label.
• If a field remains inactive, check every AND rule and remember that an inactive source contributes an empty value to downstream rules.
• If a custom headless interface displays a different state, compare its schema version and evaluation order with the current product response, then rely on the server rejection rather than a client-calculated price.

Related: Create groups and reusable choices, Storefront fields and pricing, and Store API and Blocks.