About Roles and Groups

A role relates members in the application context to information and activities managed in that context. Roles help to group people who have similar duties in the context in a way that makes sense for the team. When people are invited to become a member of an application context, the context manager must assign at least one role, such as Designer or Reviewer, to each person. Members in a context can be assigned to more than one role. The set of role assignments for each member is displayed on the Members table.

Although some roles and groups are provided when your organization and application contexts are created, additional roles can also be defined for each context from the Members table if the context is not using a shared team or if the shared team being used can be locally extended.

The context manager role has special authority to create and organize the application context, invite or remove team members, and manage the operations of the context. In project or program contexts, a context manager role also manages project or program tracking information.

The user who creates the context is automatically assigned to the context manager role. To share the management of the application context, a context manager can assign other members to a context manager role. The context manager roles available are as follows:

The Guest role allows a person to view an application context without actually being invited as a member. The following permissions apply to participants assigned to the Guest role for a particular context:

Access to information in an application context can be controlled by using roles. Each role is associated with a system group that has the same name as the role. As a context manager or administrator, you can set policy access control rules for each system group using the Policy Administration utility. Additionally, as the owner of an object, you can grant or remove access control permissions for the object using the Edit Access Control action. For example, when a new file is uploaded or a new folder or part created, the person who creates that object is responsible for setting the access to the information.

For information on the roles that are available in each Windchill solution and the access control permissions that can be set, see Access Control Overview.

Groups are used to manage access control to information, limit the visibility of actions, provide access to email communication, and invite participation in meetings. For example, meeting attendees can be invited to meetings and pages can be sent through email by group.

There are system groups that are used with context teams, as well as user-defined groups that can be created and maintained in the organization and site contexts, or created and maintained through an enterprise directory server. System groups are used to manage team role membership and are maintained only in the Windchill database. This section describes the system groups that are used with teams. For more information about user-defined groups that you can create in Windchill, see Groups (Organizations) or Creating a New Group.

Each role that is defined in a context team or team template has a corresponding system group automatically created with the same name. For example, the system role group for the Change Admin II role is CHANGE ADMINISTRATOR II and the system role group for the Members role is MEMBERS. Users added to a role are automatically added to the corresponding system group. The context manager can then create access policies for system groups using the Policy Administration utility. The policies are enforced whenever the roles are used.

The following additional system groups are created for use with context teams:

• A Team Members group contains all team members in the application context. This group is created in each application context. Windchill maintains this group; you cannot manually change the membership of this group.

• A set of system groups representing the organizations of the members in the context team. Each group contains all of the people from one organization who are members of specific application context. As team members are added and removed, the organization groups for the team are automatically updated. When a user from a new organization is added to a context, the system automatically creates the system group to hold the members of the organization. The name of each system group is the name of the organization. Windchill maintains this set of groups; you cannot manually change the membership of the set of groups.

In some places, a team organization group is shown using the organization name and, in other places, it is shown as xxxx_ORG, where xxxx is the internal number associated with the organization.

For example, assume that an application context is created and people from Company A are added to the context team as members in the roles available in the team. This action creates the following system groups:

Later, people from Company B are invited to and join the context. Then, all team members in Company B are added to the Team Members group, and an additional group called Company B is created. This group contains only those team members from Company B.

If people are added to a team using the Guest role, those people are not members of the team and are not added to the Team Members group nor to the set of system groups representing the organizations of the members in the context team.

Additionally, you can use the dynamic roles that are available in the Policy Administration utility when creating access control policy rules in the organization and site contexts. Dynamic roles represent the context team and organization groups that are maintained for each context team. For example, the Context Team Role: Engineer role that is available from the Roles tab when creating an access control policy rule represents the Engineer system group associated with context teams and shared teams. The rules created for dynamic roles are inherited by the child contexts of the organization context where the rules were created. You must create the rules in a domain that is a parent of the domain used in the application context. For additional information on using dynamic roles, see Using Dynamic Roles to Centralize the Administration of Access Control Rules.