Teamcenter Organisation Structure Design: A Practitioner's Configuration Guide

Why Organisation Structure Is a Foundational PLM Decision

Before the first item is created in Teamcenter, someone has to answer a set of questions that will shape every workflow, access rule, and data governance decision the system ever makes. How are your groups structured? Who owns which data? How do roles map to business functions? Can the structure accommodate future growth without a full reconfiguration?

Organisation structure in Teamcenter is not an administrative formality. It is the architectural layer on which access control lists (ACLs), workflow assignments, volume management, and data classification are all built. Design it well and the system scales cleanly. Design it poorly and you spend years patching access rules, fighting permission inconsistencies, and explaining to audit teams why a supplier can see engineering drawings they should never have touched.

This article walks through the five primary design considerations that experienced implementation teams work through when defining Teamcenter organisation structures: hierarchy and locations, role design, business process alignment, data management and access control, data segregation, and future scalability.

1. Hierarchy: Mapping the Current Organisation

The starting point is always a clear picture of the customer's current organisational reality — not the aspirational org chart on the website, but the actual operating structure that drives day-to-day engineering work.

Geographic locations: Is the organisation operating from a single site, or are teams distributed across multiple countries and time zones? In Teamcenter, the group-subgroup hierarchy often follows geographic or business-unit boundaries, and getting this wrong early creates painful rework.
Department distribution: Determine whether departments like Design or Manufacturing Engineering are centralised (one team, one location) or distributed (the same function exists across multiple sites). Distributed departments need careful consideration — do they share a single group, or operate as subgroups?
Functional roles: Before configuring groups and roles in Teamcenter, define the functional categories: Who creates data? Who reviews it? Who approves it? Who simply needs read access to consume it downstream? Structuring roles around these categories — author, reviewer, approver, viewer — gives a clean foundation for workflow assignments and ACL design.
Contract and supplier users: External users introduce a separate layer of complexity. Clarify upfront whether contract engineers, suppliers, or partners need any access to Teamcenter, and if so, what kind. Data security requirements for external users are usually much more restrictive than for internal staff, and designing the org structure without accounting for them often leads to provisioning workarounds later.

Teamcenter Organisation hierarchy view showing multi-site group/subgroup structure — Screenshot: Example Teamcenter Organisation hierarchy view showing a multi-site group/subgroup structure — Engineering (UK, DE, IN), Manufacturing, and Procurement as top-level groups with functional subgroups beneath each.

2. Defining Roles and Groups Correctly

Groups and roles are the building blocks of Teamcenter's access model. Groups represent the organisational unit a user belongs to — typically a department or business function. Roles define what the user does within that group — for example, Engineer, Designer, Reviewer, or DBA.

The most common mistake at this stage is creating too many roles in an attempt to model every nuance of the HR org chart. In practice, fine-grained access control is better handled at the ACL and workflow level, not by multiplying roles. A clean, deliberately limited set of roles that map to real process functions is far easier to maintain than a role list that mirrors every job title in the company.

Key principles for role design

Design roles around what users do in the process — not who they are in the org chart.
Keep role counts manageable: most implementations work well with 6–12 standard roles per business area.
Consider whether roles need to be global (visible across all groups) or localised to specific business units.
For workflow-heavy environments, align role names directly with the workflow signoff positions — this simplifies template configuration and reduces signoff assignment errors.

Teamcenter Organisation application showing group expanded with assigned roles and user membership — Screenshot: Teamcenter Organisation application showing a group expanded to display assigned roles (Engineer, Designer, Reviewer, DBA) and user membership within each role.

3. Aligning the Structure to Business Processes

The organisation structure does not exist in isolation — it directly shapes how workflows behave, how tasks are assigned, and how dynamic that assignment needs to be. Two questions matter most here.

1

Do workflows need dynamic task assignment?

Design-time Decision

In many Teamcenter implementations, workflow tasks are assigned at runtime — meaning the person initiating the workflow selects the reviewer or approver from a group or role, rather than it being hardcoded in the template. This is common in organisations where the right approver depends on context: the part type, the programme, the geography.

If the organisation structure is not designed to support this flexibility — for example, if relevant users are scattered across groups in a way that makes it impossible to define a clean signoff pool — then runtime assignment becomes unreliable. The org structure needs to account for this from the start, not be retrofitted after workflows are already configured.

2

How do functional roles map to workflow positions?

Best Practice

Roles defined in the Teamcenter organisation should directly correspond to roles used in workflow signoff panels. When they do not match — for example, when organisational roles are too granular or too generic relative to what the workflow templates expect — configuration becomes brittle and prone to signoff assignment failures at runtime.

The cleanest implementations define a small, stable set of functional roles during the organisation design phase, and then reference those same roles consistently in all workflow templates. Any deviation from that convention should be a deliberate, documented exception — not an improvisation.

4. Data Management and Access Control

Access control in Teamcenter is driven by the organisation structure. ACLs are typically configured against group/role combinations, and the choices made when defining groups and roles have a direct and lasting impact on how granular — and how maintainable — that access model becomes.

Data categorisation and classification

Before any ACLs are configured, define a data classification scheme: what categories of product data exist (Engineering, Manufacturing, Commercial, Supplier), and which groups should have access to each at which privilege level. This classification exercise is frequently skipped in favour of jumping straight to configuration — and the result is almost always an ACL model that is inconsistent, difficult to audit, and expensive to change.

1

Owning-group-based access

Most Common

In owning-group-based access control, the group that creates an object automatically has default ownership-level privileges on it. ACLs then define what other groups can do — read, write, delete — relative to the owning group. This model works well for organisations with clear departmental ownership of product data, where Engineering owns design objects and Manufacturing owns process planning objects.

2

Project-based access

Higher Complexity

Project-based access control allows cross-functional teams to collaborate on specific programmes or product lines, with access defined by project membership rather than group ownership. This model is more flexible but significantly more complex to administer — especially as product programmes proliferate. If project-based access is required, plan for a formal project lifecycle management process as part of the implementation scope.

Managing external user access

External users — contractors, suppliers, Tier-2 partners — require explicit identification and targeted access control. The common failure mode is treating external users as simply another group in the standard hierarchy, which often results in overly permissive access as ACL rules propagate in unexpected ways. External user groups should be explicitly marked and excluded from broad ACL rules, with access granted on a specific, time-bounded basis where possible.

Teamcenter ACL editor showing group/role access rule matrix for Engineering, Manufacturing, and External Supplier groups — Screenshot: Teamcenter ACL editor showing a group/role access rule matrix — read, write, delete, change ownership privileges mapped against Engineering, Manufacturing, and External Supplier groups for a Part Item object type.

5. Data Segregation: Getting Volume Management Right

Volume assignment in Teamcenter is a frequently underestimated aspect of organisation structure design. In Teamcenter, volumes — the physical storage locations for dataset files — are typically assigned at the group level. When volume management is not planned as part of the org structure design, the result is a flat, monolithic volume layout that becomes a significant constraint when environments need to be cloned, backed up, or migrated.

Principles for clean volume management

Separate volumes by functional group: CAD engineers in the Engineering group should write to Engineering volumes; Manufacturing engineers to Manufacturing volumes. This logical separation enables targeted backups, environment cloning, and capacity management by function.
Design for clonability from the start: If there is any probability that a development, test, or staging environment will need to be cloned from production — which there almost always is — volume layout needs to be designed to support that cleanly. Monolithic volume layouts where all groups write to the same volume set make selective environment cloning impractical.
Plan volume naming conventions early: Volume names and paths are not trivial to change after go-live. Establish a naming convention that reflects the group/function/geography structure before any data is loaded.

Volume assignment matrix showing Engineering, Manufacturing, and Procurement groups mapped to separate volume sets — Diagram: Volume assignment matrix showing how Engineering, Manufacturing, and Procurement groups map to separate volume sets, with a notation showing the impact on environment cloning workflows.

6. Future Scalability: Designing for Change

Organisations change. Sites are acquired. Business units are restructured. New product lines are added. A Teamcenter organisation structure that cannot accommodate growth without a significant reconfiguration effort is a structural liability that compounds over time.

Location and function expansion

When designing the group hierarchy, ask the question: if a new site were added tomorrow, how many configuration objects would need to change? The answer should ideally be small — add the new subgroup, assign the appropriate roles, and inherit the existing ACL framework. If the answer is "we would need to revisit the ACL model, the workflow templates, and the volume layout," then the structure has not been designed for scalability.

ACL and workflow flexibility

ACL rules and workflow templates that are tightly coupled to specific group names — rather than role names or object type conditions — become brittle when the organisation changes. Wherever possible, design ACLs around roles and conditions rather than explicit group references. This means that adding a new group or subgroup does not automatically require ACL rework — the new group simply needs to be assigned the appropriate roles, and the existing rules apply.

The same principle applies to workflow templates. Templates that reference specific groups by name rather than roles require modification every time the org structure changes. Templates that reference roles — particularly system roles or functional roles defined in the organisation model — survive restructuring far more cleanly.

1

Preferred: Role-based ACL design

Recommended

ACL rules reference roles (e.g. Engineer, Reviewer) rather than explicit group names. New groups can be onboarded by assigning the correct roles — no ACL rework required. Workflow templates referencing the same role names continue to function correctly.

2

Avoid: Group-name-hardcoded ACLs

Higher Maintenance

ACL rules reference specific group names directly (e.g. Engineering_DE, Engineering_UK). When a new site is added or a group is renamed, every affected ACL rule and workflow template must be reviewed and updated. At scale, this creates significant maintenance overhead and introduces the risk of security gaps during transitions.

Summary Reference: Organisation Design Dimensions

The table below consolidates the five design dimensions and the key questions that should be answered before any configuration begins.

Design Dimension	Key Questions	Configuration Impact	Risk if Skipped
Hierarchy & Locations	How many sites? Are departments centralised or distributed?	Group / subgroup structure	Structural rework
Roles & Groups	What functional roles exist? How many are genuinely distinct?	Role definitions, user provisioning	Role proliferation
Business Process Alignment	Are workflow assignments dynamic or static? Who approves what?	Workflow templates, signoff pools	Runtime signoff failures
Data Management & Access	What data classification scheme applies? Owning-group or project-based?	ACL configuration, data governance	Over-permissive access
Data Segregation	Which groups need separate volumes? How will environments be cloned?	Volume assignments, storage layout	Migration complexity
Future Scalability	How easily can new sites or groups be added? Are ACLs role-based?	ACL design pattern, BMIDE deployment planning	Compounding maintenance cost

Key Takeaways

Organisation structure is an architectural decision, not admin work. Every ACL rule, workflow template, volume assignment, and data governance policy inherits from it. Get it right before configuration begins.
Map the real operating structure, not the aspirational org chart. The Teamcenter hierarchy should reflect where data is actually created and consumed — including geographic distribution, department scope, and external user needs.
Design roles around process functions, not job titles. A clean set of functional roles (author, reviewer, approver, viewer) outperforms a role model that mirrors every position in the HR system.
Use role-based ACLs wherever possible. ACL rules that reference roles rather than explicit group names survive organisational change. Group-hardcoded ACLs create compounding maintenance overhead over time.
Separate volumes by functional group from the start. Volume layout is difficult to change after go-live. Design for environment clonability from day one — it will be needed.
Test scalability before go-live. Ask how many configuration objects would change if a new site were added. If the answer is large, the structure needs rethinking before it carries production data.