Precise Data Handling with List of Values (LOV) in Teamcenter

One of the most reliable ways to introduce errors into a PLM data model is to allow free-text input on properties where the valid values are well-defined. Part classification codes, compliance approval states, material designations, retail identifiers — these are fields where controlled vocabularies aren't just desirable, they're operationally necessary. Inconsistent property values break downstream queries, corrupt BOM reporting, and cause data validation failures during migration.

Teamcenter addresses this through its List of Values (LOV) feature — a configurable mechanism in BMIDE that restricts, guides, and in some cases auto-populates the values a user can enter against a property on any business object. This article covers the three LOV types available in Teamcenter, when to use each, and four real-world implementation patterns that demonstrate how LOV capabilities can be combined to solve complex data entry requirements.

What is a List of Values in Teamcenter?

A List of Values (LOV) is a BMIDE-configured feature that defines a controlled set of permissible values for a specific property on a Teamcenter business object. Rather than accepting arbitrary text or numeric input, a property with an LOV attached presents the user with a predefined selection — either as a dropdown, auto-complete, or cascading dependent list.

LOVs serve several important functions in a PLM environment:

Data consistency — Prevents variant spellings, abbreviations, and free-form entries that produce duplicate or unmatchable values in searches and reports.
Process integrity — Ensures properties used in workflow conditions, ACL rules, or integration mapping always carry values the downstream system can parse.
User efficiency — Replaces manual lookups with searchable, filtered value lists, reducing the cognitive load on engineers who need to enter standardised data.
Multi-language support — LOVs can be configured with locale-specific display labels while storing a consistent internal value, supporting global deployments.

LOVs are attached to properties during BMIDE configuration and can be made conditional — applying only to specific object types, groups, or roles — through BMIDE condition logic.

The Three Teamcenter LOV Types

Teamcenter provides three distinct LOV types, each suited to different update frequency, data volume, and runtime query requirements. Selecting the right type for a given use case has a direct impact on both maintainability and system performance.

1

Classic LOV

Template-managed

A Classic LOV stores its value list directly within the BMIDE template. Values are defined at configuration time and deployed as part of the standard BMIDE template deployment cycle.

When to use: Classic LOVs are well-suited for stable, low-change value sets — compliance approval states, specification categories, engineering change types — where updates are infrequent and can be scheduled as part of a planned deployment.

Characteristics:

Values are embedded in the BMIDE template and cannot be changed at runtime without a redeployment.
Support for display descriptions alongside values, configurable to show or hide the description in the client.
Can store the selected value's description in a separate property on the same object (useful for code + label patterns).
Support cascading (dependent) LOVs — the values in one LOV filter the values available in a second, based on a parent selection.

Key limitation: Adding or removing values requires a full BMIDE template deployment, which typically involves planned system downtime in production environments.

2

Batch LOV

No downtime updates

A Batch LOV stores its value list in the Teamcenter database rather than in the BMIDE template. Values are managed via an XML file and loaded using the bmide_manage_batch_lovs utility — a process that does not require system downtime.

When to use: Batch LOVs are the correct choice for any property whose value list changes frequently — supplier codes, material grades, part classification tags, project codes — or where the business owner needs to update values without engaging the PLM configuration team for a formal deployment.

Update process:

Define initial values in an XML file and load using bmide_manage_batch_lovs.
To add, modify, or remove values: edit the XML and re-run the utility. No template redeployment required.
No production downtime needed for value list updates.

Key advantage: Batch LOVs give operational agility. A business analyst can maintain the value set by updating the XML and running the load utility — without touching the BMIDE template or scheduling a deployment window.

3

Dynamic LOV

Runtime database query

A Dynamic LOV queries the Teamcenter database at runtime and presents the result as the valid value list for a property. The values are not pre-stored — they are derived from live Teamcenter data each time the user accesses the field.

When to use: Dynamic LOVs are appropriate when the valid values for a property are themselves managed as Teamcenter objects — for example, selecting a revision from a list of currently-released specifications, or choosing an active supplier from the vendor master.

Considerations:

The query executes at runtime, so performance is sensitive to data volume and query complexity. Always test under realistic data loads before deploying to production.
Query scope and filter conditions must be carefully designed to return manageable result sets.
Best suited to scenarios where the "list" is inherently tied to live Teamcenter data — not for static reference tables.

Four Implementation Patterns: Solving Real Business Requirements

The following four patterns represent requirements that arise regularly in Teamcenter implementations. Each maps to a specific LOV type and configuration approach — and in some cases, requires combining multiple LOV capabilities.

Pattern 1 — Frequently Updated Value Lists (e.g. Colour attribute)

The requirement: A Colour property on a Part business object needs to support frequent additions and removals from its value list — driven by an ongoing materials management process. The business cannot afford system downtime each time the list changes.

The solution: Batch LOV

Create a Batch LOV in BMIDE and attach it to the Colour property. Manage ongoing updates through the XML + bmide_manage_batch_lovs utility cycle.

BMIDE Batch LOV definition screen showing LOV name and type set to Batch for the Colour attribute — BMIDE screenshot: Creating a Batch LOV — the LOV definition screen showing the LOV name, type set to "Batch", and the XML structure used to define initial values for the Colour attribute.

Update values in the XML — BMIDE screenshot: Creating a Batch LOV — the LOV definition screen showing the LOV name, type set to "Batch", and the XML structure used to define initial values for the Colour attribute.

Terminal showing bmide_manage_batch_lovs utility command syntax and successful completion output — Terminal / command prompt screenshot: Running the bmide_manage_batch_lovs utility to load the Batch LOV XML file, showing the command syntax and successful completion output.

Item revision properties. — Terminal / command prompt screenshot: Running the bmide_manage_batch_lovs utility to load the Batch LOV XML file, showing the command syntax and successful completion output.

Operational note: Once the Batch LOV is defined in BMIDE and deployed as part of the initial template, all subsequent value updates happen exclusively through the XML + utility cycle. No further BMIDE deployments are required for value list changes.

Pattern 2 — Showing Value plus Description in the Client (e.g. Package Code attribute)

The requirement: A Package Code property needs to display both the code value and its human-readable description in the UI — helping engineers select the correct code without needing to memorise what each code means.

The solution: Classic LOV with description display enabled

Create a Classic LOV in BMIDE where each value entry includes both a value field and a description field. Attach this LOV to the Package Code property. By default, Teamcenter renders both the value and description in the client-side selection list.

BMIDE Classic LOV configuration for Package Code showing value and description columns populated — BMIDE screenshot: Classic LOV configuration for the Package Code attribute, showing LOV entries with both value and description columns populated, and the attachment to the Package Code property on the target business object.

Active Workspace Package Code field showing LOV dropdown with code values and descriptions — Active Workspace client screenshot: The Package Code field in an open Part form, showing the LOV dropdown with both code values and their descriptions visible in the selection list.

Pattern 3 — Showing Values Only, Hiding Descriptions (e.g. Compliance Approval attribute)

The requirement: A Compliance Approval property has an LOV where each value has an internal description, but the UI should only show the value — not the description. The description is for administrator reference only and should not be exposed to end users.

The solution: Classic LOV + LOV_hide_desc preference

Create a Classic LOV in BMIDE as normal. Then configure the LOV_hide_desc site-level preference — this preference is not present in Teamcenter by default and must be created manually. Add the LOV name as a value in this preference. Teamcenter will then suppress the description column in the client for any LOV listed in this preference.

Configuration steps for LOV_hide_desc:

Navigate to Edit → Options (in Rich Client) or the Preferences section in the administration environment.
Create a new preference named LOV_hide_desc at Site protection scope.
Set the value to the internal name(s) of the Classic LOV(s) whose descriptions should be hidden.
Multiple LOV names can be listed; all will have their descriptions suppressed.

Teamcenter Preferences showing LOV_hide_desc at Site level with Compliance Approval LOV name as value — Teamcenter Preferences administration screenshot: The LOV_hide_desc preference created at Site level, showing the Compliance Approval LOV name entered as a preference value.

Preference search. — Teamcenter Preferences administration screenshot: The LOV_hide_desc preference created at Site level, showing the Compliance Approval LOV name entered as a preference value.

Pattern 4 — Storing Value and Description in Separate Properties (e.g. Retail Code + Retail Address)

The requirement: A Retail Code property needs an LOV where the selected code value is stored in the Retail Code attribute, while the corresponding description (in this case, the retailer's address) is automatically stored in a separate Retail Address attribute on the same business object. Both attributes need to be populated from a single LOV selection.

The solution: Classic LOV with description-to-property mapping

Create a Classic LOV in BMIDE where each entry has a value (the retail code) and a description (the retailer address). When attaching this LOV to the Retail Code property in BMIDE, use the LOV attachment configuration to map the description field of each LOV entry to the Retail Address property. When a user selects a retail code, Teamcenter automatically populates Retail Code with the value and Retail Address with the corresponding description.

BMIDE LOV attachment configuration showing description column mapped to Retail Address property — BMIDE screenshot: The LOV attachment configuration for the Retail Code property, showing the description column of the LOV mapped to the Retail Address property on the same business object. The mapping panel should be clearly visible.

BMIDE UI. — BMIDE screenshot: The LOV attachment configuration for the Retail Code property, showing the description column of the LOV mapped to the Retail Address property on the same business object. The mapping panel should be clearly visible.

Active Workspace Part form showing Retail Code and auto-populated Retail Address fields after LOV selection — Active Workspace client screenshot: A Part form after a Retail Code has been selected, showing both the Retail Code field populated with the code value and the Retail Address field automatically populated with the corresponding address from the LOV description.

LOV Type Comparison Reference

Use this table as a quick reference when selecting the appropriate LOV type for a given implementation requirement:

Criteria	Classic LOV	Batch LOV	Dynamic LOV
Value storage location	BMIDE template	Teamcenter database	Not stored — queried at runtime
Update method	BMIDE template deployment	XML + `bmide_manage_batch_lovs` utility	Automatic — reflects live TC data
Downtime required for updates	Yes	No	Not applicable
Value + description display	Supported	Value only (standard)	Depends on query output
Description-to-property mapping	Supported	Not supported	Not supported
Cascading / dependent LOV	Supported	Limited	Supported (query-based)
Hide description (`LOV_hide_desc`)	Supported	Not applicable	Not applicable
Performance at scale	No runtime impact	No runtime impact	Query-dependent — test carefully
Best for	Stable, low-change value sets; code + description patterns	Frequently changing value lists; operational updates without deployment	Values derived from live TC objects (supplier master, released specs)

Implementation Guidance and Common Pitfalls

Before deploying LOVs in a production environment, implementation teams should address several practical considerations:

Plan the LOV type selection upfront

Changing LOV type after go-live — particularly moving from Classic to Batch — requires data migration planning and a template redeployment. The right choice at design time avoids expensive rework. Ask the client: how often will this value list change, and who will own the update process?

Govern the `LOV_hide_desc` preference carefully

The LOV_hide_desc preference operates at Site scope, meaning it applies globally. If description suppression is required for only specific user groups or roles, this approach will not provide the granularity needed — consider rendering stylesheet configuration instead.

Test Dynamic LOVs under realistic data volumes

Dynamic LOVs execute a live database query every time a user opens the field. In environments with large data sets, poorly scoped queries can cause noticeable UI latency. Always benchmark Dynamic LOV performance against production-representative data volumes before go-live.

Multi-language considerations

For global deployments, LOVs can carry locale-specific display labels. Configure these in BMIDE using the locale management tools to ensure engineers in different regions see values in their preferred language while the stored internal value remains consistent for integration and reporting purposes.

LOV conditions and BMIDE conditional attachment

LOVs can be attached conditionally — presenting different value lists for the same property depending on object type, owning group, role, or other BMIDE conditions. This pattern is powerful for environments where the same property (e.g. Part Category) has different valid values for Engineering versus Manufacturing objects. Plan condition logic carefully to avoid LOV applicability gaps.

Key Takeaways

Choose Classic LOV for stable, low-change value sets where description display, description-to-property mapping, or cascading lists are needed — these capabilities are unique to Classic LOVs.
Choose Batch LOV whenever the value list changes frequently or must be maintained without PLM team involvement. The XML + utility approach removes the deployment dependency entirely.
Use Dynamic LOV only when the valid values are inherently derived from live Teamcenter objects — and always validate performance under realistic data volumes before deploying.
The LOV_hide_desc preference applies at Site scope. Use it only when description suppression is required universally; for group- or role-specific control, rendering stylesheets provide finer granularity.
Description-to-property mapping (Pattern 4) eliminates the need for separate workflow or ITK logic to populate linked attributes — a clean, maintenance-free approach to code + label data entry patterns.
LOV type selection is a design-time decision with long-term consequences. Changing type post-go-live carries migration and deployment overhead — get it right in the solution design phase.