Handling Mandatory Attributes During Teamcenter Migration

Overview

One of the most common data governance challenges in Teamcenter implementations is the conflict between enforcing mandatory attributes on new data while simultaneously migrating existing legacy records that lack those same values. Attempting to solve both with the same mechanism — typically the Operation Descriptor in BMIDE — fails in practice: it either lets bad new data through or blocks valid legacy records from being imported.

This article explains the root cause of this conflict, walks through three solution approaches for handling mandatory attributes during Teamcenter migration, and provides practical guidance on closing the data quality gap on legacy parts over time.

The Problem: Two Requirements, One Conflict

Consider a common implementation scenario. The customer has two requirements:

Newly created Part records in Teamcenter must have the Base Material attribute populated — it cannot be left blank.
Existing legacy Parts being migrated from a previous system do not all have Base Material values available. Migration must proceed without blocking on this attribute.

At first glance, requirement 1 looks straightforward: mark the Base Material attribute as Required using the Operation Descriptor in BMIDE. But this immediately breaks requirement 2. The same validation that enforces the attribute on create will fire during the migration script — and because the legacy records lack the value, every such record throws an error and fails to import.

This is not a configuration mistake. It is a genuine architectural tension that exists in almost every Teamcenter migration project where data quality rules are being tightened as part of the implementation scope.

Approach 1: Operation Descriptor

1

Operation Descriptor — Why It Is Not Enough On Its Own

Partial Solution

What it does

The Operation Descriptor in BMIDE allows you to mark a property as Required and Visible for specific lifecycle operations — Create, Revise, or SaveAs. When configured, Teamcenter enforces that the user must provide a value before the operation can complete.

Operation Descriptor configuration in BMIDE — Required property on Part object

For new data creation from Active Workspace or Rich Client, this works correctly and immediately. Users cannot create a Part without providing Base Material.

Where it breaks down

The Operation Descriptor fires on every create operation — whether triggered by a user in the UI or by a migration script running batch imports. There is no way within the Operation Descriptor configuration to distinguish between the two contexts. As a result, legacy records missing the Base Material value are rejected during migration.

The Operation Descriptor is the right tool for enforcing data entry standards on new records. It is not, on its own, a complete solution when legacy data with gaps must also be loaded into the same system.

Approach 2: Pre Action on IMAN_Save with Context Detection

2

ITK Pre Action — Distinguish UI from Migration Context

Recommended for Complex Scenarios

How it works

Instead of using the Operation Descriptor, implement a Pre Action extension on the IMAN_Save operation for the Part business object. Within this custom ITK code, the logic distinguishes between two contexts:

Part created via the UI by a business user — enforce the mandatory check and return an error if Base Material is NULL.
Part created by the migration script (running under a designated migration user) — skip the mandatory check and allow the import to proceed.

Differentiating UI creation from migration script execution

The key mechanism is a custom Teamcenter preference — for example, c1_skip_attribute_check_for_migration_users — which stores the user IDs of all accounts used to execute migration scripts. These are typically dedicated system or DBA users that are not used for normal business activity.

In the Pre Action on IMAN_Save, the code reads the session user identity and checks whether it is present in the preference list:

Session user is in the migration list — skip the Base Material null check. The record imports successfully.
Session user is not in the list — apply the mandatory check. If Base Material is NULL, return an error message and prevent the save.

Custom preference c1_skip_attribute_check_for_migration_users in Teamcenter preference manager — Custom preference `c1_skip_attribute_check_for_migration_users` — configuration in Teamcenter preference manager

This approach handles both requirements cleanly within a single implementation: new records created by business users are always validated, and legacy records imported by migration scripts are always accepted regardless of attribute completeness.

Trade-offs to consider

Requires server-side ITK customisation, which increases maintenance overhead and needs to be ported during Teamcenter upgrades.
Each new mandatory attribute added in the future requires a corresponding update to the extension logic and the preference.
The migration user accounts must be strictly controlled — if a business user were assigned a migration user ID, they could bypass mandatory validation.

Approach 3: Pre-Populate Legacy Data in Staging

3

Enrich Data Before Migration — No Customisation Required

Preferred When Feasible

When to consider this approach

If customisation is something the customer wants to avoid — for reasons of upgrade cost, resource constraints, or a preference for configuration-only solutions — there is a viable alternative: correct the legacy data before it enters Teamcenter, rather than accommodating incomplete data within the system.

How to assess feasibility

Run the following checks with the customer before recommending this path:

What is the volume of Part records with NULL values for Base Material? If it is a small set, manual or scripted correction in a staging database is practical. If it runs to tens of thousands of records with no clear source of truth, this approach may not be viable.
Can the customer provide the Base Material values for the affected records? In most cases this data already exists — in the ERP, a legacy manufacturing system, or a spreadsheet. The material has been manufactured; the attribute is missing only in the source system's data model.
Is there time in the migration schedule to run a data enrichment pass before the cutover import? Even a two-to-three-week enrichment window can eliminate the need for customisation entirely.

If the answer to all three is yes, the process is straightforward: correct the Parts in the migration staging database so that all records have Base Material populated, then run the standard Operation Descriptor configuration to enforce the attribute going forward. No customisation required.

Solution Comparison

The table below summarises the three approaches to help select the right path for a given project context:

Approach	Pros	Cons	Best When
Operation Descriptor (make attribute required)	Simple, no-code configuration; enforces immediately on new records	Breaks migration — rejects records with NULL values; no context awareness	No legacy data
Pre Action on IMAN_Save (user-ID context check)	Handles both scenarios cleanly; scalable to multiple attributes via preference	Requires ITK customisation; upgrade porting overhead; migration user governance needed	Large legacy volume, customisation acceptable
Pre-populate in staging (enrich before import)	Avoids customisation entirely; cleanest long-term state	Requires customer effort to source missing values from ERP or other systems; needs time in schedule	Small-medium volume, data available in source systems

Closing the Gap on Legacy Records Over Time

Whichever approach is used to handle the immediate migration challenge, there remains a longer-term data quality concern: the legacy Parts that were imported without Base Material values are now in the live system. How do you get them corrected without a dedicated remediation project?

A practical and operationally low-friction approach is to embed the correction into normal business processes:

Add a validation check to BOM release workflows. Before a BOM can be released, the workflow validates that all child Parts have Base Material populated. Any legacy Parts used as BOM children that still lack the attribute are flagged at release time.
Require correction at point of use. When a legacy Part is selected for inclusion in a new BOM or a change notice, prompt the user to update Base Material before the transaction can proceed. This creates natural correction momentum without a dedicated cleanup programme.
Track remediation progress. Use a Teamcenter saved query or a reporting utility to track the count of Parts still missing Base Material over time. Set a target completion date and communicate progress to data owners.

Workflow validation check — Base Material completeness gate on BOM release process

This pattern ensures that data consistency is progressively enforced without creating a one-time, high-effort remediation project — and it ties the correction directly to real business activity, which tends to produce better adoption and follow-through.

Key Takeaways

The Operation Descriptor alone will not resolve the mandatory attribute vs. legacy migration conflict — it enforces validation on all create contexts, including migration scripts.
A Pre Action on IMAN_Save with context detection solves both requirements in a single implementation but introduces ITK customisation and maintenance overhead.
Pre-populating legacy data in staging is the cleanest solution when data volume and timeline permit — it avoids customisation entirely.
Whichever approach is chosen, build a point-of-use correction mechanism into business workflows to progressively close the legacy data quality gap over time.
There is no single correct answer — the right choice depends on legacy data volume, customer resource capacity, and tolerance for server-side customisation.