Best Practices for Using Local and Shared Teams
To manage your user community most effectively, analyze how best to organize your users at the Site or organization level. Where possible, create user-defined groups at the Site level or organization level and shared teams at the organization level and then use those groups and teams when creating application contexts.
When deciding which roles should be used in shared and local teams, be sure to check the team templates that will be used so you can match the roles in the context teams with the roles used in the team templates as appropriate.
Designing Context Teams
To provide users the most effective access to business data, it is important to use context teams that are designed not only for precise access control, but are also designed for optimal system performance.
Any site that expects to have thousands of products, projects, or libraries should take special care to observe the following guidelines when designing a structure for context teams. Potential optimizations may be found in these guidelines even for team designs that have long been in use. Smaller sites may also benefit from these optimization techniques.
It is often easiest to design team structure based entirely on local teams. However, local teams are very memory and processing power intensive business objects. The more elaborate and fine-grained a team’s structure, the greater the demand it places on system resources, such as:
• Caches
• Database queries
• Queue-based processes, such as the Recompute Queue
• Searches and general user interactions within the system
Very large and complex team structures, multiplied by the thousands of products and containers that use them, can place heavy demand on system resources. Complex team structures can not only slow down team-specific functionality, but in extreme cases, the demands they place on system resources can adversely impact overall system performance. Therefore, careful planning is important to design an optimal team structure that serves business needs and does not negatively impact performances.
The primary motivation in designing a team structure is to meet business requirements around permissions for different segments of the user community for accessing content within application contexts. Use the following guidelines in your team design process.
Categorize permission needs
Permission needs for your users generally fall into two categories: whether access rights should be based on a user's role in an application context; or whether access rights should be granted to the user, independent of the user's role in a context. Making this distinction will help you determine whether access should be granted to context-independent participants, or to context-specific participants.
Context-independent participants
For participants who require access to objects, whether or not they are a member of the application context where the objects reside, create access control rules using the following participants: users, user-defined groups, organizations, or pseudo roles.
For example, suppose all users in an organization need to have Read permission on Specification documents in the Released state in every public product within the organization. Enforce these access rights through a policy access control rule defined in the organization’s /Default/PDM domain granting the organization participant Read permission for the Specification document type in the Release state.
Context-specific participants
For participants who require access to objects residing in an application context based on their role in the context, create access control rules using system groups and dynamic roles. When creating access control rules for roles, consider whether the rule should be for a dynamic role, if the permission needs for that role are the same between contexts, or if the rule needs to be created for a system group because the permission needs for the role change between application contexts.
For example, suppose users who are responsible for designing a product must have Create and Modify permission for specific types of data. This only applies to products where they are assigned design work. Enforce these permissions through the dynamic roles associated with designers, in shared or local teams.
When creating an application context, consider using a shared team if the team roles and participants in the roles are the same between a set of contexts. If the team roles or participants in the roles change between the application contexts, use a local team. If the changes between application contexts are minor, consider using a shared team that is extended locally.
A mix-and-match of options is certainly possible; it is not necessary to pursue a single option for all cases. For example, you may choose shared teams for library contexts while using local teams for some sets of product and project contexts and shared teams extended locally for other sets of product and project contexts.
 |
For broad-based permission requirements, consider using context-independent participants. This will keep the team size to an optimal level and reduce the impact on system processing resources. For permissions needs that vary between contexts, use context-specific participants.
|
The following tables provide greater detail about the various techniques for managing permissions for teams and their impact on performance.
|
System resource efficiency
|
 |
|
When best suited
|
Where the permissions requirements for certain groups of participants do not change from one application context to another.
|
|
How to use it
|
The participants should not be added to the team at all. Instead, they should be granted necessary permissions via access control rules.
|
|
Examples
|
Example 1
An entire organization needs Read access to specific types of data in every public product within the organization. In such a case, one option might have been to add all the users in the organization to the Guest role in every product. This is a processing-intensive approach. Instead, users can be provided Read access via access policy rules to specific object types in a suitable administrative domain, such as the organization’s /Default/PDM domain.
Example 2
A particular group of users perform the functions of Compliance Review in every application context. Establishing a Compliance Review role and adding the same users to that role in every application context adds unnecessary overhead. Instead, the group of users can be provided necessary permissions via access policy rules for a Compliance Review user-defined group, in a suitable administrative domain, such as the Site’s / (Root) domain.
|
|
Additional considerations
|
For users that are not members of the application context team, the application contexts will not be listed in the Product, Library, Program, or Project List page in the user interface. However, users can search for them. If the users have appropriate permissions, the application contexts will be found. Once accessed, the application contexts will be loaded into the recently accessed lists in the Navigator and can be found there for subsequent use.
If such users need to access actions that are not automatically visible to non-team members, the Configure Actions for Roles settings on the team may be used to make such actions visible to non-team members. Such rules may be automatically supplied via context templates to new contexts. Some functionality, such as participation in Workflows, may also need to be set up differently for non-team member users.
The access policy rules needed for such users to navigate to different types of data within the application context may vary on a case-by-case basis. Those permissions should be identified and appropriately granted.
|
|
More information
|
|
System resource efficiency
|
 |
|
When best suited
|
• The participants require access to objects residing in an application context based on their role in the context.
• The same team structure can be applied to a number of similar application contexts, with little or no change.
• The same users or groups function in the same roles in all of those application contexts.
• Can be extended locally to meet additional needs (see Additional considerations below).
|
|
How to use it
|
• Shared teams are often used for Library teams because of the generic nature of permissions to be provided to users.
• In other cases, multiple Shared teams may be created to serve different sets of Products and Projects.
|
|
Additional considerations
|
Shared teams are most efficient when not extended locally. Extending the team locally creates a local team instance, which reduces some of the performance benefit the shared team is expected to provide. Depending on how extensively the shared team is modified in every local team, the true benefit of the shared team may not be realized at all.
|
|
More information
|
|
System resource efficiency
|
 |
|
When best suited
|
• The participants require access to objects residing in an application context based on their role in the context.
• The team structure is specific to each application context.
• The participants that function in the team roles are specific to each application context.
|
|
How to use it
|
• Create broad groupings of users based on responsibilities.
• Add the groups to specific roles on the team.
• Do not create unique user groupings for each individual context. Consider using reusable user groups.
|
|
Additional considerations
|
Ideally, the number of participants needing to be in the local team is kept to an optimal number.
|
|
More information
|
There are some common practices to avoid when designing teams. The following table lists several practices and their shortcomings.
|
Inefficient Team Design Practice
|
Shortcomings
|
Best Practice
|
|---|---|---|
|
Adding every user in the organization to the Guest role (or any other role) in every team to grant Read permission to application context data.
|
Very large team structures place heavy demand on system resources.
|
Provide basic access permissions using policy rules. Keep the number of users who need to be directly associated to a team to an optimal number.
|
|
Creating very precise control on permissions by creating hundreds of roles for every team.
|
Very large team structures place heavy demand on system resources.
|
Keep in mind the performance trade-off of defining many specialized roles. Keep the number of roles in a team to an optimal number.
|
|
Using product or library templates to specify the same policy access control rules that should be created for team roles in all products or libraries.
|
This results in unnecessary duplication where the same policy access control rules are created for the same role in every product.
|
Where possible, create policy access control rules for dynamic roles at the Organization level, instead of duplicating them in every application context. For more information, see Using Dynamic Roles in Access Control Rules.
|
|
Unique user groups are created on an ad hoc basis for role assignments in products. The groups are not reused and are specific to a single product.
|
Can result in many user groups that have similar participant memberships. This complicates the maintenance of user groups and overloads the LDAP.
|
Organize users in reusable user groups instead of creating unique user groups for each context. Alternatively, associate users directly to teams instead of creating user groups and associating those groups to roles. The second method is not as efficient as the first.
|
Other Optimization Techniques
The following are some useful system optimization techniques related to teams.
• Consider cleaning up team memberships once contexts have reached end-of-life status. The DeleteLocalTeamRoles utility deletes local team roles from an existing application context. For more information, see Deleting Local Team Roles.
• Tune cache sizes for PrincipalCache and RemoteObjectIdCache following the best practice guidelines. This ensures these caches are able to effectively serve the needs of team structures. For more information, refer to the following knowledge base articles.
• Consider using the PopulateConfirmedUsersInCache utility to pre-populate entries in the PrincipalCache so the cache is primed at system startup. For more information, refer to the following knowledge base article: https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS115189.
• For optimal cache utilization, perform regular maintenance of participants to resolve disconnected status. For more information, see Managing Disconnected Participants.
• Consider if setting the property wt.inf.team.wtusersUseAccessPolicyRules to true is appropriate for your site. When set to true, the system generated ad hoc rules are not added to participants when an application context is being created from a template. For more information, refer to the following knowledge base article: https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS180319.