Working with Lists of Values

This chapter provides guidelines to administrators for working with lists of values within Siebel Business Applications. It includes the following topics:

About Lists

A list is a set of values that populates when a user accesses a list (such as a drop-down or pop-up list) in the user interface. There are two types of lists in Siebel CRM applications:

Static lists. A static list is a selection list with values that change only when administrators change them. An example of a static list is a list containing postal abbreviations for states and countries.
This chapter focuses on the administration of static lists. In Siebel CRM, static lists are stored in a table named S_LST_OF_VAL and are referred to as List of Values or LOVs. Administration tasks include creating and modifying values in an existing list, deactivating values when you do not want them to appear, and how to constrain what values appear in a list based on the selection of another list.
Dynamic lists. A dynamic list is a selection list that usually contains transactional data. An example of a dynamic list is a list containing account names.
Dynamic lists are typically rendered through a pick applet, such as the list used to select an account for a contact. However, they can be configured to appear as drop-down or pop-up lists.

You can view data for lists of values by navigating to the Administration - Data screen, then the List of Values view. For information on configuring static and dynamic lists, constrained pick lists, and multilingual list of values (MLOVs), see Configuring Siebel Business Applications.

Siebel Business Applications come with numerous lists of values that support the static lists used in Siebel screens. You can use these lists of values as they are, or you can modify them to support your organization’s requirements.

Caution: While most LOVs (such as Account Type, Contact Type, Service Request Area, and so on) are completely customizable, some LOV types control special application behavior so it is recommended that you exercise caution when modifying them. For more information, see Modifying a List of Values.

Adding a New Value to an Existing List of Values

To add an item to an existing list of values so that it appears in that list, you must know its type. You can find out the type by querying the list of values list to determine the type associated with a specific display value. Then you can create a new record with that type. For example, in the Accounts list you can see the Service Agreement Type list. Initial settings are Gold and Silver. You might want to add another setting of Bronze to this list. The procedure in this topic uses this example.

To identify the list of values type for a display value

Navigate to the screen displaying the list to which you want to add a value (for example, the Accounts screen).
Select the list and make note of one of the choices.
For example, in the Accounts screen, select the Service Agreement Type list and make note of the value Gold.

Tip: Be sure to note the capitalization and spacing of the choice.
Navigate to the Administration - Data screen, then the List of Values view.
In the list of values list, perform a query in the Display Value field, using the value you note in Step 2.
In the list of records that is returned, identify the appropriate record by reviewing the entries in the Type field.
List of values types usually have names that relate to the field labels in the screens where they are used. In this example, you look for a type with a name similar to Service Agreement type. In this case, you will identify the correct LOV type as SRV_AGREE_TYPE.
When you create a new value for this list, you use this type.

Note: If unclear about which LOV type to use, consult the definition of the Applet, BusComp, and Pick List defined in the Repository. For more information, see Configuring Siebel Business Applications.

Adding the New Value

Complete the following procedure to add a new value to an existing list of values.

Note: The ability to edit LOVs (create, edit, or inactivate workspace-enabled seed data) in the UI in Runtime Repository (RR) environments, such as QA and Production, is supported in Siebel CRM 19.3 update and later releases.

To add a new value to an existing list of values

Navigate to the Administration - Data screen, then the List of Values view.

Create a new record by completing the fields described in the following table. For a description of all other list of values fields, see List of Values Fields.

Field	Comments
Type	Select a type for the list of values. For example, select SRV_AGREE_TYPE.
Display Value	Type in the new value for the list of values. For example, Bronze.
Language Independent Code	Type in the Language Independent Code (LIC) for the list of values. To help with multilingual deployments, it is recommended that the LIC be a capitalized version of the Display Value. For example, BRONZE. Note: The combination of list of values Type field, Display Name field, and Language Independent Code field must be unique.
Order	Type in a number to indicate the numerical order in which the value appears in a list. For example, if the order numbers for Gold and Silver are 1 and 2, then the order number for Bronze could be 3.

Clear the LOV cache by clicking Clear Cache.
For more information on the LOV cache, see Clearing the Cache.
After you have cleared the cache, you can navigate to a screen and select the new value in the related list. For example, you can navigate to the Accounts screen, select a record from the Accounts list, and then select Bronze in the Service Agreement Type list for the record.

Clearing the Cache

A particular list of values is cached the first time a user opens a list that uses the list of values. This feature improves performance by avoiding having to retrieve the list from the Siebel database when subsequently using the list. However, this feature also means that updates to a list of values do not appear in a list until you clear the cache. Clearing the cache instructs the application to read the updated values out of the Siebel database and display them.

Users who log in after you add or change a list of values can see the addition or change that you made. However, in order for you to see the changes that you made in real time, you must perform one of the following actions:

For either the Web Client or the Siebel Developer Web Client, clear the cache.
For the Siebel Developer Web Client, log out of the application and then log back in.

To clear the cache

Navigate to the Administration - Data screen, then the List of Values view.
In the List of Values list, click Clear Cache.

List of Values Fields

Many LOV attributes, such as Target High, Target Low, or Weighting Factor, are only used by specialized Siebel C++ code. Where these attributes are defined, modify them only as described in the specific documentation for that product area. If these attributes are not defined out-of-the-box, then you can leverage them for other purposes appropriate to your business needs. Use Siebel Repsitory to extend the PickList Generic BusComp by adding fields mapped to the corresponding column on the S_LST_OF_VAL table. For more information about the PickList Generic BusComp and about configuring static lists and pick maps, see Configuring Siebel Business Applications.

The following table shows the fields for List of Values records. Not all fields for list of values records appear in the standard user interface. You can use the Columns Displayed option in the applet menu (the cogwheel icon) to add or remove fields from the list.

Field	Description
Type	The specific category of list of values. For example, the SR_AREA LOV Type is used to store the possible areas under which a Service Request can be filed, and the MR_MRS LOV type is used to store the possible personal titles for a Contact (such as Mr., Mrs., Dr. and so on). To determine which LOV is used by a particular list, refer to the Pick List definition in the Siebel Repository as explained in Configuring Siebel Business Applications.
Display Value	Only display values for the user’s current language appear in this list. See also the description of the Language Independent Code field.
Translate	A check box that, when checked, indicates that internationalization is needed. This field is used by the Oracle development team to indicate that a particular LOV requires translation and does not affect any application functionality.
Multilingual	A check box that, when checked, indicates that a particular list of values Type has been multilingually-enabled. See also the description of the Language Independent Code field.
Language Independent Code	For LOV types that have been marked as Multilingual, the Language Independent Code (LIC) is used to provide a shared identity for a given LOV across all implemented languages. The LIC and Display Value are different for multilingual lists of values (MLOVs). MLOVs allow a single logical list item to support multiple display values for users who are accessing the application in different languages. For example if the MR_MS (Personal Title) list of values were multilingual, then there might be three list of values items with a LIC of Mr. These lists of values might have a display value and language of Mr. (English-American), Señor (Spanish - Modern), and Herr (German), respectively. German users see Herr in the Personal Title list, Spanish users see Señor and English users see Mr. Although the display values vary across language instances, the value stored in the Siebel database when a user selects any of these values is always the same. That is, there is a single LIC (Mr.) associated with all three records (Herr, Señor, and Mr.).
Parent LIC	The Language Independent Code of a parent list of values. This field is used in hierarchical lists of values, where the values that appear in a list are constrained by the value selected in the parent list of values. For more information, see Constrained Lists of Values.
Replication Level	This field is used by Siebel Remote for internal purposes only and is not for customer use. For all customer-related LOVs, the value for Replication Level should be All.
High	This field has specific functionality associated with it in some out-of-the-box LOV Types, such as ACCNT_REVENUE_SIZE. Where this field is defined, modify it only as described in the specific documentation for that product area.
Low	This field has specific functionality associated with it in some out-of-the-box LOV Types, such as ACCNT_REVENUE_SIZE. Where this field is defined, modify it only as described in the specific documentation for that product area.
Order	The numerical order in which a value appears within a list. Note: Through configuration, you can override the Order to force a different sort specification. For more information, see Configuring Siebel Business Applications.
Active	A check box that, when checked, indicates that the value appears to the user, and that when unchecked, indicates that the value does not appear to the user.
Language Name	The language used for the Display Value field in the list of values.
Target Low	This field is used only by specialized Siebel C++ code. Where this field is defined, modify it only as described in the specific documentation for that product area.
Target High	This field is used only by specialized Siebel C++ code. Where this field is defined, modify it only as described in the specific documentation for that product area.
Weighting Factor	This field has specific functionality associated with it in some out-of-the-box LOV Types, such as ACCNT_REVENUE_SIZE. Where this field is defined, modify it only as described in the specific documentation for that product area. This field is used by Siebel Assignment Manager Only. For more information, see Siebel Assignment Manager Administration Guide.
Bitmap	This field is no longer used.
Description	A description of a specific value. This field is for informational purposes only and does not affect application behavior.

Modifying a List of Values

To modify a value in a list, you must know its display value and type. You can find out the type by querying the list of values list for a specific display value. For example, if you must make a change to the value 1-ASAP in the Priority drop-down list in the Activities screen, then you can do so using the steps outlined in the following procedure.

Caution: While most LOVs (such as Account Type) are completely customizable, some LOV types control special application behavior so it is recommended that you exercise caution when modifying them. For example, the recurrence patterns Daily, Weekly, and Monthly in Siebel Calendar are stored as LOVs but the ability to add, modify, or delete these LOVs is not supported since they affect specialized calendar functionality. Use caution when modifying an LOV that is part of the seed data. Modifying some LOV fields that are used programmatically by the application can adversely impact standard Siebel functionality.

Some important considerations to note before modifying LOVs include the following:

Do not change the Language Independent Code values for an LOV because the internal Siebel CRM application uses the Language Independent Code field.
Some LOVs are for use only by the internal Siebel CRM application. Do not modify these lists of values. For example, the list of values SOURCE_TYPE (Internal) and list of values types that begin with REPOSITORY, WFR, or WF in the Type field name are for internal use only.
Some LOV modifications can have unwanted results. For example, changing all LOVs in the Siebel CRM application to uppercase or changing the Language Independent Code from the Siebel standard can result in values not appearing or appearing improperly.

Note: Modifying a Display Value field does not automatically update records that have been populated with the old value. For example, if you change Ms. to Miz in the Display Value field, then Miz appears in the list, but all contact records that were previously entered with Ms. in the Personal Title field still have Ms. in the Personal Title field. If the Display Value field is MLOV-enabled, however, you will see the new value after clearing the cache.

To modify an item in a list of values

Navigate to the Administration - Data screen, then the List of Values view.
Perform a query to locate the record you want to change.
For example, you might query for a value of 1-ASAP in the Display Value field. In this example, a list of records appears that includes the display value that you enter. Multiple records can appear, and the records can have different types.
In the list of records, select the record that you want to modify, and change the record.
To see the list of values modification in the application, click Clear Cache.
For instructions about how to clear the cache, see Clearing the Cache.

Deactivating a Value in a List of Values

Deleting LOVs is not recommended since it may lead to referential integrity problems in the database and unexpected application behavior. Rather than deleting LOVs or values in an LOV, deactivate them as described in the following procedure.

Only the active values in a list appear to users, inactive values do not appear to users. Inactive values are not deleted.

Caution: For example, if you deactivate the value Commercial in the Account_Type list of values, but account data with an Account Type of Commercial exists, then you might introduce inconsistencies in your data. If you want to deactivate a value, then clean up the account records first in the Siebel database.

To deactivate a value in a list of values

Navigate to the Administration - Data screen, then the List of Values view.
Query for the record that you want to deactivate.
Select the record that you want to deactivate.
In the Active field, click the check mark to clear the field.
Click Clear Cache.
You can navigate to the list of values to see that the value no longer appears.

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.

Modifying LOVs Using Siebel Enterprise Integration Manager

You can modify LOVs in Design Time Repository (DR) and Runtime Repository (RR) environments by importing LOVs using Siebel Enterprise Integration Manager (EIM). For information on importing LOV data and on how to run EIM jobs, see Siebel Enterprise Integration Manager Administration Guide.

Modifying LOVs Using REST API

You can modify LOVs in Design Time Repository (DR) and Runtime Repository (RR) environments by importing multiple LOVs using REST API. The ability to load LOVs using REST API is provided by the LOV Import Service business service, which is available in both DR and RR environments.

To modify LOVs using REST API

Upload multiple LOVs using, for example, an external tool such as SOAP UI.

To upload multiple LOVs, you must:

Use the UpsertLOV method of the LOV Import Service, which is updated in both DR and RR environments.
Define the following key attributes in the DR environment because they dictate where the LOVs will be created - these attributes are optional and can be ignored for RR environments (which only have a MAIN workspace):
- WorkspaceName. The name of the workspace where LOVs will be imported to.
- ParentWorkspaceName. The parent workspace name under which the workspace resides.
Define additional attributes, such as the field names from the LOVs business component.

Use the following template as an example, and copy as many as is necessary of the block under List of Values to create the desired number of records:

{"body":{ 
   "WorkspaceName":"dev_sadmin_ContactCreation",
   "ParentWorkspaceName":"MAIN", 
   "SiebelMessage":{ 
      "MessageId":"",
      "MessageType":"Integration Object",
      "IntObjectName":"List Of Values", 
      "IntObjectFormat":"Siebel Hierarchical",
      "ListOfList Of Values":{ 
      "List Of Values":[ 
      { 
      "Order By":"1", 
      "Name":"REST_LOV_TEST",
      "Replication Level":"All",
      "Type":"LOV_TYPE", 
      "Translate":"Y", 
      "Multilingual":"N",
      "Language":"ENU",
      "Active":"Y", 
      "Description":"REST_LOV_TEST",
      "Sub Type":"",
      "Value":"REST_LOV_TEST" 
      },
       { 
      "Order By":"1", 
      "Name":"REST_LOV_1",
      "Replication Level":"All",
      "Type":"REST_LOV_TEST", 
      "Translate":"Y", 
      "Multilingual":"N",
      "Language":"ENU",
      "Active":"Y", 
      "Description":"REST_LOV_1",
      "Sub Type":"",
      "Value":"REST_LOV_1" 
      },
       { 
      "Order By":"2", 
      "Name":"REST_LOV_2",
      "Replication Level":"All",
      "Type":"REST_LOV_TEST", 
      "Translate":"Y", 
      "Multilingual":"N",
      "Language":"ENU",
      "Active":"Y", 
      "Description":"REST_LOV_2",
      "Sub Type":"",
      "Value":"REST_LOV_2"
      },...

After you run the REST API call, check that the LOVs have loaded into your application.

For example, to locate the LOVs listed in the sample provided in the previous step, do the following:

Navigate to the Administration - Data screen, then the List Of Values view.
Click Clear Cache to make sure that it has the most current information.

Click New Query and in the Type field, search for the following:

[Type]=REST_LOV_TYPE or [Name]=REST_LOV_TYPE

The search results return a list of the LOVs that were loaded, for example, as follows:

LOV_TYPE	Display Value	Language-Independent Code	Language Name	Order	Active
LOV_TYPE	REST_LOV_TEST	REST_LOV_TEST	English-American	1	Yes
REST_LOV_TEST	REST_LOV_1	REST_LOV_1	English-American	1	Yes
REST_LOV_TEST	REST_LOV_2	REST_LOV_2	English-American	2	Yes

Modifying LOVs in Runtime Repository Environments

You can directly modify LOVs in Runtime Repository (RR) environments, such as QA or Production, as follows:

By navigating to the Administration - Data screen, then the List of Values view in Siebel Business applications.
By importing LOVs using Siebel Enterprise Integration Manager (EIM), see Modifying LOVs Using Siebel Enterprise Integration Manager.
By importing LOVs using REST API, see Modifying LOVs Using REST API.

It is still possible to maintain LOVs strictly within DR environments and migrate them to RR environments - in such cases, your particular business requirements will dictate the appropriate way to manage LOVs.

Changing LOVs in RR environments is similar to changing LOVs in DR environments. However, note that unlike development environments, RR environments do not require you to open a workspace in order to modify LOVs.

About Modifying LOVs in RR Environments

Since you can modify lists of values (LOVs) in both DR and RR environments, a potential conflict arises when you have changed LOVs in either DR or RR and you want to perform a full or incremental migration. For example:

If the same record exists in both DR and RR and the record is modified in DR but not in RR, then which record takes priority?
If the same record exists in both DR and RR and the record is modified in RR but not in DR, then which record takes priority?
If the same record exists in both DR and RR and the record is modified in both DR and RR, then which record takes priority?

Seed Migration Priority

To resolve any conflicts that might arise when migrating from a DR to an RR environment, a system preference called Seed Migration Priority has been introduced. You can set Seed Migration Priority in the RR environment to one of the following values:

Source. If Seed Migration Priority is set to Source, then precedence is given to the seed data in the DR environment.
Target. If Seed Migration Priority is set to Target, then precedence is given to the seed data in the RR environment.

Note: The Seed Migration Priority system preference by default does not exist in Siebel database. If Seed Migration Priority is not set at all, then the default behavior is to assume Target as the priority and precedence is given to the seed data in the RR environment.

Caution: Prior to completing a full migration, set the value of the Seed Migration Priority system preference in the target database. Post full migration, do not modify the value of the Seed Migration Priority system preference. For any subsequent incremental migrations, the Seed Migration Priority setting must not be changed (it should remain the same as it was during full migration). Should you need to change the value of Seed Migration Priority, then full migration must be run again.

Note: The Seed Migration Priority system preference works as a conflict-resolution mechanism and applies only if there is a conflicting change during full or incremental migration (any new LOV data will migrate as normal). A conflict occurs when an existing LOV record is modified in both the DR and RR environments.

Example of Conflict Resolution for Full Migration

The following table shows how conflicts are handled during full migration from a DR to an RR environment.

If you do the following before migration:	Conflict	The seed record in RR when `Seed Migration Priority = 'Source'`	The seed record in RR when `Seed Migration Priority = 'Target'`
Modify record in DR only	No	DR record is imported to RR.	DR record is imported to RR.
Modify record in both DR and RR	Yes	DR record is imported to RR.	RR record is retained.
Modify record in RR only	Yes	DR record is imported to RR.	RR record is retained.

Example of Conflict Resolution for Incremental Migration

The following table shows how conflicts are handled during incremental migration from a DR to an RR environment.

If you do the following before migration:	Conflict	The seed record in RR when `Seed Migration Priority = 'Source'`	The seed record in RR when `Seed Migration Priority = 'Target'`
Modify record in DR only	No	DR record is imported to RR.	DR record is imported to RR.
Modify record in both DR and RR	Yes	DR record is imported to RR.	RR record is retained.
Modify record in RR only	No	RR record is retained.	RR record is retained.

Note: For incremental migrations, conflict resolutions are made only for those records which are modified in the DR (since incremental migration carries only delta changes from the DR).

Example of How Inserts are Handled During Full or Incremental Migration

The following table shows how inserts are handled when migrating from a DR to an RR environment.

If you do the following before migration:	Conflict	The seed record in RR when `Seed Migration Priority = 'Source'`	The seed record in RR when `Seed Migration Priority = 'Target'`
Insert a new record in DR	No	DR record is imported to RR.	DR record is imported to RR.
Insert a new record in RR	No	RR record is retained.	RR record is retained.
Insert a new record with the same Name, LIC and Type in both DR and RR	Yes	DR record is imported.	RR record is retained.

Users must log out of the application and then back in again for any changes to take effect.

About Conflict Resolution

The following points summarize how conflicts are resolved during migrations:

Only conflicting records honor the Seed Migration Priority setting. For non-conflicted records, the regular migration rule (that is, migration of data from source to target) applies.
New records in both (DR and RR) environments are handled as follows:
1. New records created in DR are always migrated to RR no matter whether the Seed Migration Priority is Source or Target.
2. New records created in RR are always retained in RR no matter whether the Seed Migration Priority is Source or Target.
3. If a new record is created with the same name in both DR and RR, then the following behavior applies:
  - If Seed Migration Priority is Target, then source DR records are skipped and target RR records are retained.
  - If Seed Migration Priority is Source, then source DR records are imported and target RR records are deleted.
Deleting a seed record is a modification, which follows the same rules that apply for record modification. All deleted records become inactive.

Modifying LOVs in Integration Workspace in DR Environments

There is no workspacing of LOVs at the development workspace level in DR environments. However, each integration branch (including the MAIN branch) has its own full copy of seed data or LOVs and there is complete isolation of the seed data across the integration branches (there is parallel development isolation at the integration workspace level, not at the development workspace level). As a result, LOV changes carried out by any user are immediately visible across the entire scope of a specific integration branch – that is, changes are visible at the integration branch level as well as at all the development branches under it.

Up until Siebel CRM 20.2 Update release, it was mandatory to create a development workspace in order to modify LOVs, even though there was no isolation at the development workspace level. To make LOV development in DR environments more intuitive, given that LOV modifications happen at the scope of the integration workspace, LOV modifications should be performed directly against the integration workspace. This would eliminate the necessity of creating a development workspace if the user wants to make LOV changes only (and is consistent with the isolation model used for seed data). Also, this is required for executing scripts that update LOVs on MAIN or integration workspaces.

As of Siebel CRM 20.3 Update release, you can modify LOVs by opening either the development workspace or integration workspace in a DR environment. When you open the development or integration workspace in a DR environment and modify LOVs, the changes will always happen at the integration workspace level. This is the default behavior. You can enable or disable LOV modification in the development workspace of DR environments by setting the DisableSeedUpdOnDevWS system preference as follows:

If DisableSeedUpdOnDevWS is set to True, then LOV modification is not allowed in the development workspace. In this case, LOVs are read-only.
If DisableSeedUpdOnDevWS is set to False, then LOV modification is allowed in the development workspace. By default, DisableSeedUpdOnDevWS is set to False.