•Context policies

•Context data types and attributes

•Templates, including context templates, process templates, and data templates

•Context object initialization rules

•Context preferences

After you have created a context, you can update many of the administrative items that are associated with the context. The contexts that can be updated include the site context, as well as organization and application contexts.

Use the administrative utilities and specific user actions to edit the administrative items in a context. These utilities and actions are usually available to the administrator of the context. For the details on Windchill administrators, see Additional Administrative Groups on page 57 .

Each type of context has a slightly different set of administrative items that can be updated. For example, you can edit the set of life cycle and workflow templates provided in organization, product, and library contexts. Also, you can only edit the set of product, library, project, and program templates that are provided in an organization or the site context. This is because product, library, project, and program templates are not included in application contexts.

The following sections provide descriptions of administrative items, information on what is installed in the site context for each item, and how to edit the items.

Context Configuration

Configuration items identify the type of context and other miscellaneous information about the context.

There are three general types of contexts:

•Site – The site context is the top-level context. There can be only one site context.

•Organization – Organization contexts are always children of the site context. There is always at least one organization context required to have an operational Windchill solution.

•Application – Application contexts are always children of an organization context. There are four types of application contexts:

○Product

○Library

○Project

○Program

The context configuration can include the following additional items:

•You decide whether an application context is public or private. This option is only available when you are not using a shared team.

The /Default domain in private contexts, by default, inherits access control rules from the /Private domain of the organization.

The /Default domain in public contexts, by default, inherits access control rules from a solution-dependent public domain within the organization context. For projects and programs, the default public domain is the /Default/ Project domain. For products and libraries, the public domain is the /Default/ PDM domain. This configuration allows an administrator to:

○Create policies in the organization context /Default domain that apply to all public child contexts and contexts using a shared team.

○Create policies in the /Default/Project and /Default/PDM domains that apply to solution-specific child contexts.

○Create policies in the /Private domain that apply to all private child contexts; however, PTC recommends that no additional access control rules be created within this domain as those policies would be inherited by all private contexts. If additional policies are required for a given private context, create the policies using a domain in the child context.

•For application contexts created with shared teams, the default behavior is that the /Default domain in the contexts inherits access control rules from the shared team domain in the organization context where the shared team was created. The shared team domain has the same name as the shared team and is a child of the /Default domain in the organization context. This configuration allows an administrator to:

○Create policies in the organization context shared team domain that apply to all child contexts that use that shared team.

○Create policies in the Private domain that apply to all private child contexts; however, PTC recommends that no additional access control rules be created within this domain as those policies would be inherited by all private contexts. If additional policies are required for a given private context, create policies using a domain in the child context.

•For project contexts, you decide whether or not data can be shared to other contexts.

•For an organization context in Windchill solutions including projects and programs, you decide whether the project creators group is auto-populated with members of the organization. The project and program creators groups determine who can create projects and programs.