About List of Values

The List of Values (LOV) entity is one of the most important in the Siebel CRM application. It provides the values in almost every drop-down or picklist within the Siebel CRM application. For example, setting the status of a Service Request to New, In Progress, or Waiting on Customer, or the recurrence pattern for a Calendar appointment to Weekly, Daily, or Monthly. LOV’s also provide values to even more internal technical items, such as the deployment state of a Workflow Process, which are all made available in the List of Values Seed Data.

A LOV is simply a huge list of all the drop-down values throughout the Siebel CRM application that are broken out by a type, that is stored in the LOV known as LOV_TYPE. The LOV_TYPE filters each individual picklist. Using the previous examples of Service Request Status, Calendar Recurrence, or Workflow Process Status, you will see that there are three different LOV_TYPEs as follows and shown in the following image:

REPEATING_APPT_TYPE: The Calendar Recurrence LOV_TYPE.
SR_STATUS: The Service Request LOV_TYPE.
WFA_DPLY_STAT_CD: The Workflow Process Status LOV_TYPE

LOV Types: This image is described in the surrounding text.

Each LOV_TYPE has specific records/values relevant to the picklists where they are used. For example REPEATING_APPT_TYPE has the following records/values, as shown in the following image: REPAPPT_NONREPEATING, REAPPT_DAILY, REPAPPT_WEEKLY, REPAPPT_MONTHLY, and REPAPPT_YEARLY.

REPEATING_APPT_TYPE LOV: This image is described in the surrounding text.

These values appear in the application when selecting the repeating pattern for a meeting. The following REPEATING_APPT_TYPE values appear in the Repeat Type picklist, as shown in the following image: Non-Repeating, Daily, Weekly, Monthly, Yearly.

REPEATING_APPT_TYPE, LOV: This image is described in the surrounding text.

The LOV_TYPE value in this example, REPEATING_APPT_TYPE, determines which items show up in which picklist based on settings in the Siebel Runtime Repository.

There are two classes of LOVs in the Siebel CRM system. There are LOVs that can be safely modified and those that cannot be modified. There is no hard rule for this, but before modifying an LOV, administrators should consider if there is specialized functionality that might be based on the LOV. Consider the three LOVs that are used as examples here: REPEATING_APPT_TYPE, SR_STATUS, and WFA_DPLY_STAT_CD.

REPEATING_APPT_TYPE: This LOV type indicates the types of repeating patterns that the Siebel Calendar can support. Logically, adding a new one, for example, every hour, is not going to work because the underlying calendar code will have no idea what to do with an hourly appointment. Oracle does not recommend customizing this LOV type.
SR_STATUS: This LOV type indicates the current status of a Service Request. This is an example of an LOV that can be modified, but there are some considerations. Specifically, based on the underlying object definition, it is not possible to make changes to a Service Request once it is closed. Therefore, while it is possible to add to the list of status values available, there could be negative behavior were the administrator to remove or rename the Closed status.
WFA_DPLY_STAT_CD: This is an example of an LOV that must never be modified. It is controlling the behavior of a repository object. The status of a given Workflow Process can certainly change, the administrator can mark a Workflow Process as Inactive or Active. However, making changes to the possible values would have unknown and undesirable repercussions.

These examples all imply that it is not allowed or at least not recommended to change LOVs but that is not the case. For example, there is no reason not to modify Account or Contact Status values, the Service Request Areas and Sub-areas since these are completely acceptable changes.

Some guidelines on changing LOVs:

As already noted, do not change LOVs for objects that control system behavior, such as Workflow Process Status.
Be careful modifying highly specialized objects or those that illustrate unique behavior in the application. For example, if you note that closing a Service Request makes it read-only, then be careful modifying that LOV type.
As with all seed data, do not delete LOVs. If something is not desired in your implementation, inactivate the LOV. On a side note, doing so is not effective in the long run since Siebel CRM upgrades restore missing LOVs. Removing a LOV lasts until the next upgrade, while inactivating it will last forever and the upgrade process will not reactivate inactive LOVs.
Similar to the last point, do not rename LOVs. If a name change is desired, for example changing In progress to Working. In that example, it would be best to inactivate the undesired LOV and create a new active one. Failure to do so will result in the renamed LOV coming back at the next upgrade and may throw errors during the upgrade process.

Note: There are multilingual options for LOVs. These are discussed previously in the chapter on installing the environment as well as the Siebel Global Deployment Guide.