 |
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.
|
|
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
|
|
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.
|