Using Dimension Dependent LOVs With Attributes

Lists of Values (LOVs) can be set up to be dimension dependent, just as attributes. The most common scenario when using dimension-dependent LOVs is to use them along with non–dimension-dependent attributes, though other combinations are also applicable.

This topic explains four combinations of dimension dependency between attributes and LOVs, recommended practices in their setup, and use cases:

  1. Attribute with no dimension dependency used with a dimension-dependent LOV
  2. Attribute with no dimension dependency used with an LOV without a dependency
  3. Attribute with a dimension dependency used with a dimension-dependent LOV
  4. Attribute with a dimension dependency used with an LOV without a dependency

This topic does not explain how to create an LOV or how to make an LOV or attribute dimension dependent. For more information, refer to the Creating an LOV topic (here) and the Dimension Dependent Attributes topic (here).

Note: It is important to set up dimension-dependent LOVs from the start to avoid issues that could arise from setting a dimension dependency later after values have already been added to the attributes that use them. For more information, refer to the Adding a Dimension Dependency After Loading Data topic in the Dimensions, Dimension Points, and Contexts documentation here.

To illustrate the differences between the setups, the screenshots in this topic show attribute values viewed in the Context mode in the STEP Workbench

Attribute With No Dependency, LOV With a Dependency

The most typical scenario when using a dimension-dependent LOV is to use it along with an attribute that is not dimension dependent. This is used for descriptive information that is true for every language, where the value needs to appear in the local language.

This is a cost-saving benefit of ‘pre-translation’ when new products use the LOV. Customers who use a lot of LOVs for this purpose can save a lot of money.

When using an attribute without a dimension dependency and an LOV that has a language dependency, a user working in English can choose the color 'Red' for a new product. If the LOV has already been translated, the French value 'Rouge' will automatically show up, so there is no reason to retranslate this text. Every time Red is chosen, the translation is already in place.

Attribute With No Dependency, LOV Without a Dependency

Another commonly used setup is when neither the attribute nor the LOV it is using are dimension dependent. The value of the LOV is the same in every context

The typical use case for this scenario is for numbers or dates or even text that should never change, no matter which language or country is consuming the information. Many values like Y/N flags, availability dates, product weights, dimensions, and measures would not have any dimension dependencies.

Attribute With a Dependency, LOV With a Dependency

This setup is not commonly used because values in all dimension points are independent of each other due to there being separate values in each dropdown list. In this example, the value is completely different in English US, Danish DK, and French FR. 'Red' appears in English US, but the Danish word for 'Blue' and the French word for 'Black' appear in the Danish DK and French FR contexts.

If an English US user chooses 'Red,' a value will not display in the French FR context until a French FR user chooses something from the dropdown, whereas if the attribute does not have a dimension dependency and the LOV does (per the first example in this topic), if a user chooses 'Red' for English US, then 'Rød' and 'Rouge' will automatically populate in the Danish DK and French FR contexts.

Attribute With a Dependency, LOV Without a Dependency

It is a rare setup to use an attribute with a dimension dependency along with an LOV that does not have a dimension dependency because the values can be different in every dimension. In this scenario, everyone uses the same dropdown list—English US values mixed in with Danish DK and French FR values.

Although not typical, one use case for this might be an 'Available for Sale” attribute using a Y/N global LOV but with a country dependency on the attribute.

In this scenario, when an English US user chooses a value, nothing will appear in the Danish DK or French FR contexts until a user in one of those countries makes a choice from the same dropdown list.