To enable a user to create products, projects, libraries, or programs, the user must be added to the Product, Project, Library, or Program Creators group for the organization. Only members of the organization can be added to the creators groups. Additionally, organization and site administrators who are members of the organization can create products, libraries, projects, or programs; otherwise, you must be a member of the project creators group to create projects, a member of the program creators group to create programs, a member of the product creators group to create products, or a member of the library creators group to create libraries within the organization.

In Windchill ProjectLink, all members of the organization, by default, are allowed to create projects and administer the projects they create. However, if the organization is set up so that members are not automatically added to the project creators group and empowered to create projects, you must manually add members to the project creators group. Organization members must be manually added to the program creators group in order for them to create a program. Projects are considered the least formal of the application contexts (product, library, project, and program), so it is generally appropriate to allow all users to create and administer a project.

User-defined groups created at the site and organization level can be used when members create product, library, project, program, and shared teams or when access policies are defined. For example, an organization may want to define user-defined groups for each of the functional teams with membership in the organization. For example, assume that the organization defines a sales and marketing group, an engineering group, a publications group, and a quality control group. These user-defined groups can then be added as members of a product or project team without adding each member individually. Furthermore, when user-defined groups are updated, the updates can be refreshed to update all the teams referencing the user-defined groups without the need for each product or project manager to update their team membership.

For additional information about updating team membership, see Defining a Context Team.

Shared teams minimize user administration by allowing a collection of roles and associated participants (a shared team) to be used in many application contexts. Any changes to a shared team are immediately available in the contexts where the shared team is used. By default, the site administrator can create shared teams in any organization context and organization administrators can create shared teams in their organization context. Additionally, on the Creators page, you control who can create shared teams by adding users to the shared team creators group. Adding a user to this group allows the user to create shared teams from the organization Teams page.

For additional information about creating and managing shared teams, see About Shared Teams.

An organization inherits the roles defined at the site (as defined in the system roles resource bundle). All the roles from the RoleRB.rbInfo file are displayed on the organization Roles page. Organization administrators can explicitly hide the roles that they do not want their organization to use.

For more information, see Creating an Organization Context.