Constrained Lists of Values

Constrained lists of values are used to restrict the values that show up in a particular list based on the selection in some other list. For example, let’s consider a Service Request Area (SR_AREA LOV Type). If the user selects the Area Network, then the user would see Subareas of Ethernet Card or Wifi Connections. If the user selects Hardware for the Area, then the Subarea options might be Hard Drive, DVD Rom, Memory, or Other. This helps users to choose a logical combination of values to help make the nature of the Service Request clearer.

Let’s look at this example in a little more detail — it is actually a three-tier constrained picklist. That is, it has a Grandparent, Parent, Child relationship. The Grandparent dictates the possible Parent values, and the Parent dictates the possible Child values.

All three tiers are defined in the same SR_AREA LOV Type. Out-of-the-box, the high level values are those that have no parents. These can be selected in the Service Request field, Service Request Type, which defaults to External.

The Area field is populated by SR_AREA LOVs that have a parent indicated in the Service Request Type field, so any SR_AREA LOV that has a parent of External will be visible in the Area picklist unless a different SR Type is selected.

After selecting an Area, the SubArea will be constrained to the Area as described in the previous paragraphs.

The actual constraint is defined by the Parent LIC value, allowing users of the application to consistently choose appropriate children across all languages. So if the user selects Network in the Area list, then only those values that have the Parent LIC field set to Network appear in the Subarea list, while if the user selects Upgrade in the Area list, then only those values that have the Parent LIC field set to Upgrade appear in the Subarea list.

Consider a specific example where you want to add some additional Service Request Areas. The new Area value is Size and the children are Small, Medium, and Large.

• Assuming that the new Size Area will show up as a value on new Service Requests, which have a Service Request Type External, you would create a new LOV with Type SR_AREA, LIC SIZE, Display Value Size, Parent LOV External, and Language English-American.

  After defining the Size value, you would define more LOVs of Type SR_AREA with the Parent LIC Size as shown in the following table.

  Type	LIC	Display Value	Language	Parent LIC
  SR_AREA	SMALL	Small	English-American	SIZE
  SR_AREA	MEDIUM	Medium	English-American	SIZE
  SR_AREA	LARGE	Large	English-American	SIZE

• For each additional language you want to support, you would create another Area LOV with the same LIC but a different Language Code and Display Value. For French, for example, you would define an additional SR_AREA LOV with LIC SIZE, Display Value Taille, and Language French.

  For each additional language, you would define an additional number of children as shown in the following table.

  Type	LIC	Display Value	Language	Parent LIC
  SR_AREA	SMALL	Petit	French	SIZE
  SR_AREA	MEDIUM	Moyen	French	SIZE
  SR_AREA	LARGE	Grande	French	SIZE

Note: The usage of the External value to identify items in the parent list is specific to this example. To determine this value for any pair of constrained lists, reference the underlying configuration in Siebel Repository.

Constrained lists of values must first be configured in the Siebel Repository. After they are configured in the Siebel Repository, specific values in lists can be made hierarchically dependent through the List of Values view. You use the Parent LIC field in the list of values record to specify the values that appear when a value is selected in the parent list.

For more information about constraining both static lists (maintained through lists of values) and dynamic lists, see Configuring Siebel Business Applications.