Scalable Display Rules in Teamcenter BMIDE: Beyond the Obvious Configuration

What Are Display Rules in Teamcenter?

Display Rules in Teamcenter control the visibility of business objects — specifically, which groups and roles within the organisation can see a given object type in the Teamcenter client (Rich Application Client or Active Workspace). They are configured in BMIDE and apply at the object type level.

Unlike Access Control Lists (ACLs), which govern read/write/delete permissions on individual objects already visible to a user, Display Rules operate one level higher: they determine whether an object type even appears in a user's context at all. This makes them a powerful tool for simplifying the user experience and enforcing data governance — but only if they are configured correctly.

Display Rules are particularly common in scenarios where different business functions — Engineering, Manufacturing, Procurement, Tooling, Supplier Management — interact with the same Teamcenter instance but should see different sets of object types, forms, or menus. A Procurement analyst has no need to see Design Revision objects; a Classification specialist does not need to initiate Engineering Change Requests. Display Rules are the mechanism that enforces this separation cleanly.

          Design intent: Display Rules are designed to hide objects from specific groups — not
          to explicitly show them. This distinction matters when choosing the right configuration strategy for
          scalability.
        

A Common Requirement: Restrict a Menu Object to One Department

Consider a typical Teamcenter configuration scenario that arises frequently in manufacturing environments: the organisation has a custom business object — for this example, call it Menu (representing a manufacturing bill of materials menu or product catalogue entry, depending on the business context) — that should only be visible and actionable by the Procurement department.

The requirement is straightforward in principle: only Procurement users should be able to view and create Menu objects. All other departments — of which there may be many — should not see them at all.

The organisation has 35 departments defined in its Teamcenter configuration.

For the purposes of this article, the requirement applies to two related object types:

Raw Material — a custom Item or Item Revision type representing raw materials in the product structure
Menu — a related object capturing bill of materials or catalogue data for Procurement use

Only the Procurement group should be able to view and create both object types. All remaining 34 departments must have them hidden.

The Obvious Approach — and Why It Does Not Scale

The first instinct for many consultants is to configure the Display Rule by explicitly listing each group that should not see the object. With 35 departments in the organisation, that means adding 34 groups individually to the Display Rule for each affected object type.

This approach has three compounding problems:

1

Initial effort is disproportionate

High Overhead

Adding 34 groups one-by-one in BMIDE is tedious and error-prone. In real-world projects, the actual department list is often larger and subject to last-minute changes during configuration workshops. Any missed entry means a department that should not see the object type can still see it — a data governance gap.

2

Every organisational change triggers a BMIDE update

Brittle

When a new department is added to the organisation — and in active manufacturing operations, this happens regularly — the Display Rule must be updated to include it. Each update requires a BMIDE deployment, which typically means a planned maintenance window and production downtime. For a configuration that should be "set and forget," this creates an ongoing operational burden.

The problem compounds if the same hiding rule applies to multiple object types (which it will — if Raw Material is restricted to Procurement, so probably are five other related types). Every new department addition requires the same BMIDE update and deployment cycle across all affected object types.

3

Impact assessment becomes non-trivial

Risk of Errors

As the number of Display Rule entries grows, so does the risk of configuration inconsistency. A new consultant inheriting the configuration has no easy way to audit which groups are and are not covered. A group that was renamed, restructured, or duplicated during an organisational change may no longer match the Display Rule entry correctly, silently breaking the intended access control.

The Scalable Solution: Condition-Driven Display Rules

The correct approach inverts the logic. Rather than explicitly hiding each unauthorised group, configure a single Display Rule that hides all groups — and then attach a BMIDE condition that excludes the permitted group from that hiding rule.

The resulting condition is compact and readable:

u.group_name != 'Procurement'

Translated into plain language: hide this object from any user whose group name is not Procurement. Since Display Rules apply the hiding effect when the condition evaluates to true, this single condition correctly hides the object from all 34 non-Procurement groups — and, crucially, continues to do so automatically as new groups are added in future.

No BMIDE redeployment is required when a new department is created. The condition logic remains valid regardless of how many groups exist in the system.

BMIDE Display Rule configuration on Raw Material business object — BMIDE Display Rule configuration screen showing the hiding rule applied to the Raw Material business object with the condition *u.group_name != 'Procurement'* attached — highlighting the Condition field and the associated group entry.

Configuration Steps in BMIDE

The following steps walk through implementing the condition-driven Display Rule pattern in Teamcenter BMIDE. This procedure assumes familiarity with BMIDE navigation and basic data model deployment.

Step 1 — Define the BMIDE Condition

In BMIDE, navigate to Conditions under the data model tree. Create a new condition of type Expression. Set the expression to:

u.group_name != 'Procurement'

Give the condition a descriptive internal name that makes its intent clear, for example: c1_HideFromNonProcurementGroups. Meaningful naming conventions matter here — a condition with a generic name becomes difficult to audit six months later when a new consultant is trying to understand why an object type is not visible to a particular group.

BMIDE Conditions editor with c1_HideFromNonProcurementGroups expression — BMIDE Conditions editor showing the new condition *c1_HideFromNonProcurementGroups* with expression type selected and the `u.group_name != 'Procurement'` expression entered in the condition definition field.

Step 2 — Attach the Display Rule to the Target Business Object

Navigate to the target business object — in this case, Raw Material (and repeat for Menu). Open the Display Rules panel for the object.

Add a new Display Rule entry. Set the Group field to the wildcard or a representative entry representing all groups (depending on your TC version, this may be a blank entry or a catch-all group). This is the rule that applies the hiding effect.

In the Condition field of the Display Rule entry, attach the condition created in Step 1: c1_HideFromNonProcurementGroups.

BMIDE Display Rules panel on Raw Material with condition attached — BMIDE Display Rules panel on the Raw Material business object, showing the single Display Rule entry with the Condition field populated with *c1_HideFromNonProcurementGroups*.

Step 3 — Deploy the Data Model Changes

Deploy the updated data model template using the standard BMIDE deployment process. The condition and Display Rule configuration will be active on the target Teamcenter server after the next server restart or preference refresh, depending on your environment configuration.

Step 4 — Validate the Configuration

Test the Display Rule by logging into the Teamcenter client (RAC or Active Workspace) with users from at least three different group types:

A user in the Procurement group — the Raw Material and Menu object types should be visible and creatable.
A user in an Engineering or Manufacturing group — neither object type should appear in the creation dialog or search results.
A user in a newly created test group — confirm that the condition logic applies to new groups without any BMIDE changes.

That final test step is the key validation of the scalability benefit: a brand-new group, added after the Display Rule was deployed, should be correctly hidden from the object type without any configuration changes.

Teamcenter New Object dialog comparison — Procurement vs Engineering user — Active Workspace or RAC client showing the New Object creation dialog — two screenshots side by side: Procurement user (Raw Material visible in the list) and Engineering user (Raw Material absent from the list).

When to Apply the Condition-Driven Pattern — and When Not To

This approach is highly effective in a specific set of scenarios. Understanding when it is the right tool — and when it is not — is important before applying it broadly.

Apply this pattern when:

Access should be granted to one or a small number of groups, and hidden from the majority
The organisation's group structure is likely to evolve over time (new departments, restructuring)
The same hiding logic applies to multiple business objects — a shared, named condition keeps configuration consistent across all of them
Minimising BMIDE deployments for access control changes is a priority in the operational model

Consider alternative approaches when:

The requirement is to show the object to a majority and hide it from only one or two groups — in that case, explicitly listing the excluded groups may be more readable
Display Rule logic needs to be based on object properties as well as group membership — more complex compound conditions may require testing to ensure correct evaluation order
The access control requirement is better addressed by ACLs rather than Display Rules — if users need to see the object type exists but cannot access individual instances, an ACL is the correct mechanism

Scenario	Recommended Approach	Rationale
1 permitted group out of 35	Condition-Driven Rule	One condition scales indefinitely; no deployment per new group
1 excluded group out of 35	Explicit Exclusion	Single entry; condition adds unnecessary complexity
Multiple object types, same restriction	Shared Named Condition	Reuse the same condition across all objects; single change point
Object property + group combination	Compound Condition	Test thoroughly; evaluation order affects correctness
Instance-level access, not type-level	ACL (not Display Rule)	Display Rules control type visibility; ACLs control instance access

Key Takeaways

Display Rules hide objects, they do not explicitly show them. Understanding this design intent is the prerequisite for choosing the right configuration strategy.
Listing every excluded group is the obvious approach but not the scalable one. In organisations with many departments, it creates maintenance overhead and requires a BMIDE deployment every time the group structure changes.
A single condition using u.group_name != 'Procurement' replaces all 34 individual group entries. Any group added to the system in the future is automatically subject to the hiding rule without any configuration changes.
Named conditions can be reused across multiple business objects. If the same restriction applies to Raw Material, Menu, and three other types, a single well-named condition governs all of them from one definition.
Always validate with a newly created test group post-deployment. This is the definitive proof that the condition logic is working as intended and will continue to work as the organisation scales.
Know the boundary between Display Rules and ACLs. Display Rules are for type-level visibility; ACLs are for instance-level access. Using the wrong tool produces a configuration that looks correct but does not enforce the intended data governance.