Teamcenter Naming Rules: Intelligent Part Numbers, Auto-Counters & System Variables

What Are Teamcenter Naming Rules?

Naming Rules are a core BMIDE configuration mechanism that controls the format of property values on any business object in Teamcenter. They are most commonly applied to item_id and item_revision_id, but they can be attached to any attribute on any object type.

Out-of-the-box, Teamcenter generates item IDs using a basic auto-increment counter. For many enterprises, that is not enough. Engineering organisations typically need IDs that encode meaning — department codes, part classification, origin group, or sequence — so that a part number carries useful metadata at a glance, without requiring a database lookup.

Naming Rules solve this. By defining a pattern in BMIDE and attaching it to the relevant property, you can enforce that every new Item, Item Revision, Dataset, or custom business object created in the system — whether from the rich client (RAC), Active Workspace (AWC), or via an integration — receives a properly formed identifier.

Critically, Naming Rules also support conditions, meaning the same business object type can have different ID formats applied depending on the user's group, role, or other object attributes. This enables multi-division or multi-site deployments to use a single Teamcenter instance while maintaining separate, unambiguous numbering schemes.

Naming Rule Capabilities Overview

BMIDE exposes a rich set of Naming Rule capabilities. Understanding the full range before designing a solution prevents the common mistake of over-engineering with customisation what can be achieved through configuration alone.

Capability	Description	Typical Use
Fixed literal prefix / suffix	Static text included in every generated value	Department code, site identifier
Auto-increment counter	Sequential numeric counter — width and ceiling configurable	Part sequence number (e.g. 001–999)
System variables	Runtime session context: `${USERID}`, `${USERNAME}`, `${GROUP}`	Embedding creator identity in the ID
Regex pattern validation	Enforce that a manually entered value matches a defined regular expression	Free-text fields with structural rules
Condition-based attachment	Apply different Naming Rules to the same property based on BMIDE conditions	Group- or role-specific ID formats
Counter ceiling	Define max numeric value before counter rolls or errors	Preventing runaway sequence numbers

These capabilities can be combined in a single pattern. A common production pattern combines a fixed prefix, one or more system variables, a separator, and a counter — producing IDs that are both human-readable and machine-sortable.

System Variables: Embedding Session Context in IDs

System variables are one of the most powerful and underused features of Teamcenter Naming Rules. They pull information from the active session at the moment the object is created and embed it directly into the generated value.

The following system variables are available for use in Naming Rule patterns:

Variable Keyword	Resolves To	Example Output
`${USERID}`	Login ID of the user creating the object	`jsmith`
`${USERNAME}`	Full display name of the session user	`John Smith`
`${GROUP}`	Primary group of the session user	`Engineering`

Syntax for System Variables in Patterns

System variables must be wrapped in a dollar sign followed by curly braces. A variable reference therefore takes the form:

${VARIABLENAME}

For example, a pattern that embeds the creating user's ID and username, separated by a hyphen, followed by a three-digit counter:

${USERID} - ${USERNAME} - NNN

Where NNN is the counter mask — each N represents one digit position. A three-character mask produces values from 001 to 999.

BMIDE Add Naming Rule Pattern dialog — BMIDE Naming Rule editor — pattern configured with ${USERID} and ${USERNAME} system variables and NNN counter mask.

Naming Rule Pattern Anatomy

A Naming Rule pattern is composed of one or more segments. Segments can be fixed literals, system variable references, or counter masks — combined in any order to produce the target format.

Understanding each segment type is essential before building patterns for production use:

1

Fixed Literal Segment

Always Present

A fixed string that appears in every generated ID, regardless of user, group, or context. Used for organisation prefixes, product family codes, or site identifiers.

Example: PUR as a prefix produces IDs such as PUR000111, immediately identifying a purchasing-created commercial part by its number alone.

2

System Variable Segment

Preferred for Identity Encoding

Pulls a value from the active Teamcenter session at creation time. This makes the ID self-documenting — anyone looking at the item number can immediately determine who created it or which group it belongs to.

System variables are resolved once at creation and stored as the literal value. They are not re-evaluated on revision or copy unless the Naming Rule is re-applied.

Syntax: ${USERID} · ${USERNAME} · ${GROUP}

3

Counter Mask Segment

Plan Counter Ceiling Carefully

An auto-increment sequence represented by one or more N characters. Each N is a digit position. A mask of NNN generates values 001 through 999 — once 999 is reached, Teamcenter throws an error unless the counter is reset or the mask extended.

For large volumes, always use a wider mask. A five-digit mask NNNNN supports up to 99,999 objects before ceiling is reached. In practice, for enterprise deployments, a minimum of six digits is recommended to avoid ceiling management overhead mid-project.

4

Regex Validation Segment

For Manually-Entered Values

When the business requires manually entered IDs — rather than auto-generated ones — a Naming Rule can enforce a regex pattern to validate the input before the object is saved. This prevents malformed IDs from entering the system while preserving user control over the value.

Useful for legacy migration scenarios where existing part numbers must be retained but must conform to a defined format going forward.

Worked Example: User-Identity Pattern with a Bounded Counter

The following example walks through a complete Naming Rule configuration that satisfies three common requirements encountered in enterprise Teamcenter deployments:

The item ID must embed the creating user's login ID.
The item ID must embed the creating user's display name.
A three-digit sequential counter (001–999) must be appended after the user information.

Pattern Design

All three requirements are satisfied by a single pattern combining two system variables and a counter mask:

${USERID} - ${USERNAME} - NNN

With a session user whose login is jsmith and display name is John Smith, the first object created produces:

jsmith - John Smith - 001

Subsequent objects created by the same user increment the counter. Objects created by a different user embed their own user context, producing a distinct series — each series sharing a counter namespace scoped to the combined pattern value.

Attaching the Naming Rule to the Property

Once the pattern is defined in BMIDE, it must be attached to the target property. For item IDs, this is the item_id property on the relevant business object type.

Validating the Output

After deploying the BMIDE template, create a test item as a user in the target group. Confirm that the item ID resolves correctly in both RAC and Active Workspace. Also test with a second user to confirm that user context is embedded correctly and that counter sequences are independent between users.

Conditional Naming Rule Attachment

One of the most powerful aspects of BMIDE Naming Rules is the ability to attach multiple rules to the same property, with each rule governed by a condition. This enables context-sensitive ID generation — the same business object type can produce different ID formats depending on who creates it or under what circumstances.

Practical Use Case: Group-Specific Prefixes

Consider an organisation with an Engineering group and a Purchasing group both creating Items. The requirement is:

Items created by the Engineering group should receive IDs prefixed with ENG
Items created by the Purchasing group should receive IDs prefixed with PUR

Rather than creating two separate business object types, you configure two Naming Rules — one per prefix pattern — and attach each with a BMIDE condition that checks u.group_name. At runtime, Teamcenter evaluates the conditions and applies the matching rule.

Condition Types Supported

Condition Basis	BMIDE Condition Expression	Example
User group	`u.group_name == 'Engineering'`	Group-specific prefix or counter
User role	`u.role_name == 'Designer'`	Role-differentiated series
Object property value	`object.object_type == 'MyPartType'`	Type-specific format
Combined condition	`u.group_name == 'Purchasing' AND object.object_type == 'CommercialPart'`	Group + type specificity

When no condition matches, Teamcenter falls back to the unconditional Naming Rule (if one exists) or allows free-text entry. Always define a fallback rule or validation pattern to prevent uncontrolled values from entering the system when new groups or roles are added in future.

Implementation Steps

The following sequence covers the end-to-end process of configuring and deploying a Naming Rule in BMIDE. Steps assume familiarity with BMIDE navigation and basic Teamcenter template deployment.

1

Define the Naming Rule in BMIDE

BMIDE Configuration

Open BMIDE and navigate to the Naming Rules section. Create a new Naming Rule and define the pattern using fixed literals, system variable references (${USERID}, ${USERNAME}, ${GROUP}), and counter masks (NNN, NNNNN, etc.).

Set the counter ceiling explicitly. Do not rely on the default — document the chosen ceiling in your configuration workbook so the team knows when counter management will be needed.

2

Define Conditions (if required)

Required for Multi-Group Deployments

If multiple Naming Rules need to apply to the same property depending on context, define BMIDE conditions for each rule. Conditions can reference user attributes (u.group_name, u.role_name) or object properties.

Test each condition individually in a development environment before combining them. Complex nested conditions should be debugged using the BMIDE condition debug logging feature (enable logger.properties in TC_DATA).

3

Attach the Naming Rule to the Property

BMIDE Property Configuration

In BMIDE, navigate to the target business object and open the property editor for item_id (or the custom property you are targeting). Attach the Naming Rule — or multiple rules with conditions — to the property.

If attaching the rule to the OOTB item_id property, use a child business object to avoid modifying the Siemens-delivered base type directly. This preserves upgrade safety.

4

Deploy the BMIDE Template

Requires TC Server Restart

Deploy the updated BMIDE template to your target environment (DEV first, then QA, then PRD following your change control process). A Teamcenter server restart is required for the new Naming Rule to take effect.

In environments using Deployment Center, ensure the template deployment step is included in your upgrade scripts to avoid the Naming Rule being lost during a future upgrade cycle.

5

Validate in RAC and Active Workspace

Test Across Both Clients

Create test objects as users from each relevant group/role combination. Verify that the generated IDs match the expected pattern, that counters increment correctly, and that condition-driven rules apply the right pattern to the right user.

Test both clients if your organisation uses both RAC and AWC. Naming Rules behave consistently across clients, but confirm this in your specific version — client-side rendering differences in older TC versions occasionally affect display.

Key Takeaways

Naming Rules are property-level, not object-level — they can be attached to any property on any business object, not just item_id. Use this to enforce structured values across all critical metadata fields.
System variables embed creation context permanently — ${USERID}, ${USERNAME}, and ${GROUP} are resolved once at object creation and stored as literal values, making IDs self-documenting without additional metadata queries.
Plan counter ceilings before go-live — a three-digit counter (NNN) supports only 999 objects per unique prefix/user combination. For enterprise volumes, use at least five or six digits and document the ceiling in your design workbook.
Conditions enable context-sensitive ID formats — a single business object type can carry multiple Naming Rules with BMIDE conditions, delivering group-specific or role-specific numbering without separate object types or customisation.
Always define a fallback rule — when using conditional Naming Rule attachments, include an unconditional fallback or validation pattern to prevent unstructured IDs from entering the system when new users, groups, or roles are added later.
Attach rules to child types, not base types — modifying Siemens-delivered base type properties directly creates upgrade risk. Create a site-specific child business object and attach Naming Rules there to preserve upgrade safety.