Release 2018 R1 introduces the ability to add logic to User Defined Attributes (UDAs) that have Predefined Value lists, allowing you to define Dependency Contexts that determine what options are made available to your users under different circumstances.

This allows you to help narrow down the choices that your users need to make so that they do not waste time selecting values from a huge range of possibilities and help them to avoid making incorrect or nonsensical choices.

For example, say that your company needs to specify the temper applied to a given material. There might be hundreds of temper values available to choose from. By defining a Predefined List UDA to automatically narrow the available tempers based on the material that is selected, you can automate what would otherwise be a near-impossible task.

Another example could be the organizational hierarchy within a large global company that has multiple regions, with each region having multiple product lines, which in turn have multiple projects. Having a single list of all company projects could quickly become unnavigable for users looking for a particular one. But if you define lists to display only those projects that exist within a particular product line within a particular region, the choice is narrowed down to a manageable selection.

Here’s a simple example. Assume that your company has three regions, each of which has a specific product line, and each product line has three active projects:

 

You can define three UDAs for Region., Product Line, and Projects, and give them predefined lists for the values. But if you place these lists on the Cost Guide and expect your users to select the correct combination of values when costing components, there’s a very good chance they could get it wrong and spend a lot of time in the process. For example, a user could select “North America” for the region, and “Gizmos” for the product line, and “X3B” for the project – none of which match the other values.

Here’s how you could define these UDAs with Dependency Contexts to ensure only the correct values are made available, based on other selections.

Now when your users click through these attributes in order (top to bottom), each selection will determine what the next menu will offer. For example, selecting “North America” for the region ensures that only “Widgets” is available for Product Line, and only “X1A, X1B, X1C” are available for Projects:

 

The Projects UDA drop-down menu will display a completely unfiltered menu (i.e., it displays all possible items). For this small example, this is not a huge problem: only nine items show up. In a real-life situation, the user might be overwhelmed with dozens or hundreds of options. And if they select one, and then select an item in the Region or Product Line that does not support that project, their original selection will be cleared and they will need to make another selection, this time from the valid options shown.

To avoid this kind of situation, we are going to add dependency context terminators to the Product Line and Projects definitions. This are special Dependency Context definitions that take effect if none of the expected conditions are met.