A shared team consists of a set of roles and the members added to those roles (same as in context teams). Shared teams are created in an organization context and can be used as the context team for multiple application contexts that are created from the organization context. For example, assume you have created a shared team called the Product Demo Team in the Bike Company organization context. This shared team can be selected when users create application contexts (such as products and projects) when working in the Bike Company organization context. If users who are creating application contexts are members of a different organization context, then the Product Demo Team is not available. For more information, see About Contexts.

When creating a shared team, you can set whether the shared team can be extended locally when an application context using the shared team is created. To limit all context teams that select the shared team to only use the shared team, ensure that the Allow team to be extended locally in associated application contexts option is not set.

If there are no shared teams enabled when an application context is created, then the creator of the application context does not see the Shared Team field and the team created is a local team. A shared team cannot be added after an application context is created.

Any changes made to the shared team are immediately evident in all context teams that use the shared team. For example, after a change is made to a shared team, refreshing the Team page of a context team that is using the shared team displays the changes that were made to the shared team.

The following sections introduce shared team roles and describe how shared teams are managed through the use of system groups and domains.

The initial set of roles established in a shared team are:

You can add or remove roles and members to a shared team in the same manner that you add them to or remove them from a local team. See the following topics for more information:

When a context team includes both a shared team and a local team, the system adds the Shared Team Manager group as a member to the system group for the context manager. To allow you to see who is a Shared Team Manager member, the Shared Team Manager role and the context manager role remain separate on the Members table when the context team is extended locally.

For example, assume the Bike Design project has a context team that includes the General Design shared team. A member of the General Design Shared Team Manager role is Chris Taylor. Then Chris Taylor appears under the Shared Team Manager role on the Members table for the Bike Design project. However, since the Shared Team Manager group is added as a member to the Project Manager group, Chris Taylor assumes the role of the Project Manager for the Bike Design project along with other members who are in the Project Manager role in the local team.

Participants in the shared team Members and Guest roles also become members of the local team Members and Guest roles in a similar manner. The shared team Members and Guest groups are added as members to the local team Members and Guest groups. Similarly, if you add other roles to a shared team that are also in the local team, participants in the roles with the same name are considered to be in the same role. The local team Members table shows only one role with any members from both the shared team and the local team appearing under that role in the Members By Role view.

In Windchill PDMLink, if you are the context manager of the local team, an organization administrator, a site administrator, or a user who has been granted the Modify Team action, you can determine which roles and members are part of the shared team by inspecting the information provided in the Affiliation column that displays in the Members table when the view contains both local and shared team roles or members. For example, if there are two participants assigned to the Designer role in a shared team and one participant assigned to the Designer role in a local team, then all three participants are designers in the context team. All three participants display under the Designer role on the Members table when the view is Members By Role. The Affiliation column in the table identifies which members are from the shared team and which are from the local team.

In Pro/INTRALINK, if you are the context manager of the local team, an organization administrator, or a site administrator, you can determine which roles and members are part of the shared team by inspecting the information provided in the Affiliation column that displays in the Members table when the view contains both local and shared team roles or members. For example, if there are two participants assigned to the Designer role in a shared team and one participant assigned to the Designer role in a local team, then all three participants are designers in the context team. All three participants display under the Designer role on the Members table when the view is Members By Role. The Affiliation column in the table identifies which members are from the shared team and which are from the local team.

If there is only a shared team and no local team, then no additional roles display on the Members table. Additionally, the context manager role is not established in the team. Instead, the Shared Team Manager role acts as the context manager for the context. The access control policy rule set for the Shared Team Manager role gives participants in the role Full Control (All) permission for all objects in the context.

When a shared team is created, an administrative domain is created with the same name as the shared team. The parent domain of this shared team domain is the Default domain that resides in the organization context where the shared team is created. For example, assume you have created a shared team called the Product Demo Team in the Bike Company organization context. Then, the following domain structure is available from the Policy Administration utility:

When an application context is created that uses a shared team, the Default domain for the application context is created under the shared team domain. For more information, see Context and Domain Hierarchy Overview.

For example, if the Super Bike product context that uses the Product Demo Team is created, then the following domain structure is available from the Policy Administration utility:

This domain structure allows you to create a unique set of policy access control rules in the shared team domain that are then inherited by all application contexts that use the shared team.