Logical dependencies let you control which configuration options a user can select based on what they have already chosen. When you set them up in the master data information, you can apply the same rules to the product configurator.
The point is to guide the user through valid combinations only. If a customer selects a 7-gear bike, the bike type can only be a city bike or a colibri. If they select 20 or 21 gears, the only valid option is a mountain bike.
You set up the criteria in the master data information, where the config dependencies functionality lives. Start there to understand how it works before applying it to the configurator.
How logical dependencies filter configuration options
When you enter the specification on an item and you have already filled in one of the criteria, the system limits what you can choose for the related criteria. If you drill down on a dependent parameter, you might see only four selections instead of the full list, because the dependency filters out the invalid combinations.
You can tell which kind of list you are looking at from the header information. A filtered list shows up as a user config value list. A non-filtered list shows up as an information value list, displaying all the data without any dependency applied.
It is the same underlying data in both cases. The difference is that the dependency narrows it down to the valid options.
Dependencies work in both directions
The filtering is not one-way. If you delete the bike type on your item and then drill into the gear field, the list is longer because there are fewer constraints. Once you select a gear and then look at the bike type, you can only pick the options that match.
This means the logical dependencies hold up no matter which field the user fills in first. The system always keeps the combination valid.
Applying logical dependencies to the configurator
This is the base functionality of the logical dependencies in the master data information. The real value is that you can apply the same rules to the configurator, so users building a product configuration are guided through valid combinations only.
Q&A
Where do I set up logical dependencies for the configurator?
You set them up in the master data information using the config dependencies functionality. Once defined there, you can apply the same dependencies to the configurator.
What is the difference between a user config value list and an information value list?
A user config value list is filtered by the logical dependencies, so it shows only the valid options. An information value list is non-filtered and shows all the data. You can tell which one you are looking at from the header information.
Do logical dependencies only filter in one direction?
No. They work both ways. If you select a gear first, the bike type list is limited to valid options. If you select the bike type first, the gear list is limited. The system keeps the combination valid regardless of which field you fill in first.
Can you give an example of a logical dependency?
If the bike has a 7-gear setup, the bike type can only be a city bike or a colibri. If the bike has 20 or 21 gears, the only valid bike type is a mountain bike.