A conditional configurator must never end with a required choice the customer cannot see or reach. Calculate visibility from the current answers, validate only visible requirements and clear values made invalid by a later choice.
Conditions make a configurator shorter and more relevant: colour temperature and controls appear only after ‘with lighting’ is selected. But every hidden dependency also creates a risk. A previously selected option may remain hidden while still affecting the price, or the server may reject an invisible required field. Both undermine trust.
Draw conditions as a decision tree
For each group, record which earlier answers make it visible. Keep rules simple: one or a few explicit conditions are easier to test than a long formula with exceptions. Check that every route reaches a valid endpoint and that customers can go back without getting stuck.
| Event | Expected behaviour | Do not |
|---|---|---|
| Group becomes visible | Explain why and request a choice if needed | Automatically select an expensive default option |
| Group becomes hidden | Remove the invalid value or clearly retain it | Include a hidden option in the price |
| Condition changes back | Restore safely according to a documented rule | Restore an old choice arbitrarily |
| URL or browser manipulates input | Server recalculates visibility | Trust the frontend state |
Decide deliberately whether a hidden choice is cleared or temporarily remembered. Remembering it can be helpful when someone briefly goes back, but it must not affect the price or order while the group is hidden. Clear sensitive or incompatible input immediately. Put this rule in the product specification, not just in JavaScript.
Prevent circular rules in administration. Group A must not ultimately depend on A again through B. Check new rules when saving and show a readable path explaining the conflict. Let administrators preview a product journey with sample answers so they can see which groups appear and disappear before publishing.
Validate the same tree on the server
The browser helps customers navigate, but the server determines which groups are visible and required for the submitted configuration. Rebuild visibility from known option IDs. Ignore unknown fields and reject a visible requirement without a valid choice with a specific message.
Make error messages move to the correct step and announce the missing group. ‘Invalid configuration’ is not enough. Say, for example: ‘Choose a control for the selected lighting.’ If a product rule has changed in the meantime, explain that the configuration must be checked again.
Use stable option identifiers beneath the visible labels. An editor may later change ‘Electric’ to ‘Motorised control’, but old carts and order lines must remain understandable. For historical display, store the label visible when ordering alongside the identifier. The current rule still takes precedence during recovery.
Fictional example: shading with a motor option
Shading company Lichtlijn first asks for the control type: manual or electric. Motor type, power connection and an optional remote control appear only for electric operation. Customer Mila chooses electric and a remote control, then switches back to manual.
The configurator hides the electric groups and removes the motor and remote control from the calculation. The summary shows only the manual version. If Mila chooses electric again, she must deliberately confirm the motor; the old remote control does not silently reappear as a paid component. The server repeats the same visibility calculation when adding the configuration to the cart.
If the final parts go to stock or production as separate SKUs, only the current visible choice must be passed on. Yindle Connect can help translate that order structure into other systems in a controlled way.
After launch, Lichtlijn reviews which routes are often abandoned. A high drop-off immediately after power connection questions appear may mean an explanation is missing, rather than that customers do not want the option. The team improves examples and help text before changing the technical conditions.
Route-based test set
- Test every main route from the start to a valid summary.
- Go back one step and several steps after each choice.
- Clear a visible required field and check focus and messaging.
- Hide a group containing a selected, priced option.
- Manipulate unknown or hidden values in the request.
- Open an old configuration after conditions have changed.
- Test mobile, keyboard and screen reader use when content appears dynamically.
- Compare the visible summary, cart lines and order data.
Limit the number of exceptions per release. If administrators can stack arbitrary conditions, automatic cycle detection and a preview are needed. Prefer starting with a small supported rule model that can be fully tested. For unusual product logic, custom software may be a more stable alternative.
Discuss with Yindle how to keep every decision route in your configurator valid.