Attribute-Level Access Control in Teamcenter: Three Implementation Approaches

Controlling who can read or write a Teamcenter object is straightforward with standard Access Control Lists (ACLs) — you grant or deny privileges at the object level and you are done. The harder problem arises when different groups need write access to different properties on the same object. A manufacturing engineer and a design engineer may both need to open the same Part revision, but each should only be able to edit the attributes relevant to their role.

This requirement — attribute-level access control in Teamcenter — sits outside the scope of standard ACL configuration. This article examines three viable implementation approaches, explains the trade-offs of each, and provides guidance on when to use which.

Target audience: Teamcenter architects, administrators, and senior consultants evaluating access control design for multi-discipline manufacturing environments.

Understanding the Problem: Object-Level vs Attribute-Level Access Control

Standard Teamcenter ACL configuration works at the object level. You can control whether a user group can read, write, or delete a business object — but you cannot, out of the box, say "the Engineering group can edit properties A, B, C and the Manufacturing group can edit properties D, E, F on the same object."

In practice, this matters in any organisation where:

Engineering and Manufacturing teams co-own part master data but maintain separate attribute sets — for example, design tolerances versus process parameters.
Supplier or contractor users access objects that contain a mix of shareable and restricted attributes.
Compliance requirements mandate that certain properties can only be modified by specific roles.

The three approaches below each address this gap differently. The right choice depends on your client mix (RAC vs AWC), the scale of the access matrix, and your tolerance for custom code.

Approach 1: Separate Form Objects per Group

The first approach uses Teamcenter's form objects to segregate attributes by group. Instead of placing all attributes directly on the part object, you create two or more separate form business objects — one for Engineering attributes and one for Manufacturing attributes. Each form is governed by its own ACL.

1

Separate Engineering & Manufacturing Form Objects

Configuration Only

How It Works

Define a custom Engineering form (e.g., c1_EngineeringData) and a Manufacturing form (e.g., c1_ManufacturingData) in BMIDE.
Attach both forms to the Part business object via a GRM relation.
Apply ACLs so that only the Engineering group can write to the Engineering form, and only the Manufacturing group can write to the Manufacturing form.
Configure Active Workspace stylesheets or RAC client layouts to surface each form in the correct context.

BMIDE configuration showing dual form objects attached to Part via GRM relations with separate ACL assignments per group — Figure 1: BMIDE configuration — dual form objects attached to Part via GRM relations, with separate ACL assignments per group.

Limitations to Consider

Attributes stored on form objects are not directly on the part. Downstream processes — BOM reports, search queries, and ERP integrations — may not find them without additional configuration.
Form access management adds overhead: you must ensure forms inherit the correct release status in sync with the parent Part revision.
Forms are primarily designed for workflow use cases such as displaying data during a signoff task. Using them purely for access control can feel architecturally forced.

Approach 2: XML Rendering Stylesheets with modifiable="false"

The second approach stays entirely within the Active Workspace configuration layer. It leverages XML rendering stylesheets to lock the edit capability on specific attributes for specific groups — without changing the underlying data model.

2

XML Rendering Stylesheets — `modifiable="false"`

AWC Only

How It Works

Create separate XML rendering stylesheets for each group that requires differentiated access — for example, an Engineering stylesheet and a Manufacturing stylesheet.
In each group's stylesheet, set modifiable="false" on the attributes that group should not be able to edit.
Register the stylesheets in Active Workspace against the appropriate group using stylesheet registration configuration.

Users in each group will see all properties on the object but will be unable to edit those marked modifiable="false" in their stylesheet. Full read visibility is retained.

XML stylesheet snippet showing modifiable=false applied to Manufacturing attributes within the Engineering group stylesheet — Figure 2: Example stylesheet snippet showing `modifiable="false"` applied to Manufacturing attributes within the Engineering group stylesheet.

⚠ AWC-only enforcement: Stylesheet-based attribute locking applies only in the Active Workspace client. Users accessing the same object through the Rich Client (RAC) are not subject to stylesheet restrictions and can edit all properties to which they have object-level write access. If your environment includes RAC users, this approach alone is insufficient.

Limitations to Consider

Only effective in AWC. Any user with RAC access bypasses stylesheet-based locking entirely.
As the number of groups and attribute combinations grows, maintaining multiple stylesheets becomes a significant configuration overhead — and each change requires a BMIDE deployment.
Stylesheet changes require planned production downtime for BMIDE deployment.

Approach 3: ITK Pre-Condition Extension with Preference-Driven Mapping

The third approach implements attribute-level access control at the server side using an ITK Pre-Condition Extension on the property SAVE operation, governed by a site-level preference. This is the most robust and scalable option for complex access matrices and mixed client environments.

3

ITK Pre-Condition Extension + Preference Mapping

Client-Agnostic

Step 1 — Define the Access Mapping Preference

Create a site-level Teamcenter preference that maps each group to the set of properties it is authorised to edit. For example:

Preference name: prop_group_edit_mappings

Engineering:c1_designTolerance,c1_materialSpec,c1_surfaceFinish
Manufacturing:c1_processParam,c1_toolingRef,c1_cycleTime

Property internal names are listed against the group name, with each group occupying a separate preference value. Updating the access matrix later requires only editing this preference — no code change and no system downtime.

Step 2 — Implement the Pre-Condition Extension

Write a single generic ITK Pre-Condition extension and attach it to each controlled property. The extension logic is:

Read the preference prop_group_edit_mappings for the current session.
Identify the logged-in user's group from the session context.
Check whether the property being saved appears in that group's permitted list.
If permitted, return ITK_ok and allow the save to proceed.
If not permitted, return an error — the user receives a clear message that they cannot edit this attribute.

ITK Pre-Condition Extension decision flow diagram for group-to-property validation against the preference mapping — Figure 3: ITK Pre-Condition Extension — decision flow for group-to-property validation against the preference mapping.

Step 3 — Attach the Extension to Each Controlled Property

In BMIDE, attach the pre-condition extension to the SAVE operation for each property that requires group-based control. A single shared extension handles all properties — only the preference mapping needs updating when access rules change.

BMIDE extension attachment showing the same pre-condition extension applied to multiple properties on the Part business object — Figure 4: BMIDE extension attachment — same pre-condition extension applied to multiple properties on the Part business object.

Advantages of Approach 3

Enforcement is server-side and client-agnostic — applies equally in AWC and RAC, making it the only approach that fully covers mixed client environments.
Adding a new controlled property requires only attaching the extension in BMIDE and updating the preference — no new code to write.
Changing a group's access rights requires only a preference value update, executable at runtime with no BMIDE deployment or system downtime.
The entire access matrix is centralised and auditable in a single site-level preference.

Limitations to Consider

Requires server-side ITK customisation, introducing a code artefact that must be maintained through Teamcenter version upgrades.
Each newly controlled property must have the extension explicitly attached in BMIDE — a deployment step each time.
Testing and validation overhead is higher than a configuration-only approach.

Selecting the Right Approach: Decision Matrix

The table below summarises the preferred choice for each common implementation scenario:

Scenario	Approach 1 Separate Forms	Approach 2 XML Stylesheets	Approach 3 ITK Extension
Clean Engineering / Manufacturing data model separation	Ideal	Not applicable	Possible
AWC-only environment, no RAC users	Limited	Best fit	Possible
Mixed AWC + RAC environment	Limited	AWC only	Best fit
Large number of groups or controlled attributes	Overhead	Overhead	Scales well
Minimal custom code preferred	Config only	Config only	Requires ITK
Runtime access rule changes without downtime	Moderate	BMIDE redeploy	Preference only

Practical Decision Guidance

In most real-world implementations, the choice comes down to two factors: client coverage and scale of the access matrix.

When only AWC is in use and the access matrix is small

Approach 2 (XML Stylesheets) is the lowest-effort solution. It requires no custom code and stays entirely within the Active Workspace configuration layer. The critical prerequisite is confirming that RAC will not be used — stylesheet-based locking provides no protection for RAC users. If there is any possibility of RAC access in future, factor that into the decision now rather than revisiting the architecture later.

When both AWC and RAC are in scope, or the access matrix is large

Approach 3 (ITK Pre-Condition Extension) is the appropriate choice. It is the only approach that enforces attribute-level control consistently across all clients. The upfront investment in ITK development pays back in scalability — changing access rules later is a preference update, not a code change or a downtime event.

When form-based separation is already part of the data model design

Approach 1 (Separate Forms) can be appropriate where attribute sets are cleanly separable and downstream processes already account for form-based attribute storage. It is rarely the right first choice for a pure access control requirement, but may be the most natural fit when the data model already architecturally segregates Engineering and Manufacturing data onto distinct objects.

Implementation Checklist

Before configuring any approach, confirm: the full list of attributes requiring group-based control; which clients are in scope (AWC only, RAC only, or both); whether the requirement applies to editing only, or also to read visibility.

For Approach 2 — XML Stylesheets

Identify all groups requiring differentiated access and map each to the attributes it should not be able to edit.
Create and register separate stylesheets per group in the Active Workspace configuration.
Test in AWC and explicitly confirm RAC exclusion before sign-off.
Plan a BMIDE deployment window for production rollout.

For Approach 3 — ITK Pre-Condition Extension

Define the preference structure and document the initial group-to-property mappings.
Develop and unit-test the pre-condition extension in a dedicated development environment.
Attach the extension to all controlled properties in BMIDE and deploy to a test environment.
Conduct user acceptance testing across both AWC and RAC clients.
Document the extension in the site customisation log for upgrade planning.

Summary

Attribute-level access control in Teamcenter is a genuine architectural decision — not a standard configuration task. The three approaches covered in this article each address the requirement from a different angle: form-based data segregation, stylesheet-based UI locking, and server-side ITK enforcement.

For most implementations in mixed AWC/RAC environments with a non-trivial number of groups and attributes, Approach 3 is the most robust and maintainable solution. The preference-driven mapping keeps the access logic transparent and changeable without code modifications, while server-side enforcement guarantees consistent behaviour regardless of which client a user is working in.

The choice of approach should always be made with a clear picture of the current and planned client landscape, the scale of the access matrix, and the organisation's tolerance for ITK customisation in the upgrade path.

Key Takeaways

Standard ACLs are object-level only. Attribute-level control requires a dedicated implementation approach — it is not achievable through ACL configuration alone.
XML Stylesheets are AWC-only. If your environment includes any RAC users, stylesheet-based locking cannot be the sole enforcement mechanism.
Approach 3 (ITK Extension) is the only fully client-agnostic solution. It enforces access rules at the server tier, applying consistently across AWC, RAC, and any SOA-based client.
The preference-driven mapping is the key scalability feature. Changing which group can edit which attributes requires only a preference update — no code change and no system downtime.
Approach 1 (Separate Forms) suits data model segregation, not pure access control. Use it when the data model already separates Engineering and Manufacturing attributes onto distinct objects.
Establish the client scope and access matrix upfront. The correct approach is determined almost entirely by two inputs: which clients are in use and how large the group-attribute permission matrix is.

Attribute-Level Access Control in Teamcenter: Three Implementation Approaches

Understanding the Problem: Object-Level vs Attribute-Level Access Control

Approach 1: Separate Form Objects per Group

Separate Engineering & Manufacturing Form Objects

How It Works

Limitations to Consider

Approach 2: XML Rendering Stylesheets with modifiable="false"

XML Rendering Stylesheets — modifiable="false"

How It Works

Limitations to Consider

Approach 3: ITK Pre-Condition Extension with Preference-Driven Mapping

ITK Pre-Condition Extension + Preference Mapping

Step 1 — Define the Access Mapping Preference

Step 2 — Implement the Pre-Condition Extension

Step 3 — Attach the Extension to Each Controlled Property

Advantages of Approach 3

Limitations to Consider

Selecting the Right Approach: Decision Matrix

Practical Decision Guidance

When only AWC is in use and the access matrix is small

When both AWC and RAC are in scope, or the access matrix is large

When form-based separation is already part of the data model design

Implementation Checklist

For Approach 2 — XML Stylesheets

For Approach 3 — ITK Pre-Condition Extension

Summary

XML Rendering Stylesheets — `modifiable="false"`