so that the base data loaded includes files translated into the language of choice at your site. The base data that is loaded determines which language set of context templates is available.

For details on setting which language files are used when loading base data, see the Database Initializing and Data Loading chapter of the PTC Windchill Installation and Configuration Guide.

Use one of the out-of-the-box organization templates when creating organization contexts, or you can create a customized organization template, as described in the next section.

For application contexts, you can use one of the out-of-the-box product, library, project, or program templates, or you can create additional application context templates, as described in the next section.

The details of what is in each out-of-the-box context template can be found in the following chapters:

•Organization templates are described in Organizations on page 139

•Product and library templates are described in Products and Libraries on page

•Project and program templates are described in Projects and Programs on page

235 .

For information on creating context templates, see Context Templates on page 393 .

Note

The role names used in Windchill solution context templates are included as references to the <Windchill>\src\wt\project\RoleRB.rbinfo resource bundle so that when they are used, they appear in the language specified by the browser language. This means that the translated templates do not contain translated role names.

Administering Domains and Policies

This section describes how Windchill domains and policies are defined. A domain is an administrative area that defines a set of administrative policies, such as access control, indexing, and notification. Objects associated with a Windchill domain are subject to its policies.

Note

Windchill domains are not the same as internet domains.

A policy is a collection of rules designed for various types of objects associated with a domain. For example, an indexing policy consists of rules that determine the types of objects for which metadata should be entered into specified collections, when the objects belong to the domain.

Before creating a context in your Windchill solution, you should determine which domains are needed and use a template that creates the domains and the access control policies for those domains when you create the context. For details on what domains and policies are included in the out-of-the-box templates, see the following chapters:

•Organization templates are described in Organizations on page 139

•Product and library templates are described in Products and Libraries on page 173 .

•Project and program templates are described in Projects and Programs on page

235 .

For the details on creating additional context templates, see Context Templates on page 393 .

After a context is created, you can use the Policy Administration utility to administer the domains in the context.

The following sections provide information about installed domains and how to use the Policy Administration utility to administer the domains.

Context and Domain Hierarchy Overview

Context types have the following established hierarchy:

When each context is created, a set of domains is also created for use within the context. Generally, the domain hierarchy is established using the context hierarchy. A parent domain is either in the same context as its child domain or in the parent context of its child domain's context. In the following diagram, the site, organization, and library contexts are shown with one domain defined in each context. The domain hierarchy shows domain3 (in the library context) as a child of domain2 (in the organization context) and domain2 as a child of domain1 (in the site context):

The actual domain structures are determined in part by whether an application context is created as a private context or a public context, or created using a shared team. The domain structure for the /Default domain in private contexts starts under the /Private domain in the organization context. The domain structure for the /Default domain in public contexts and contexts using a shared team starts under the /Default domain in the organization context.

To illustrate the domain structures for shared team, private, and public contexts, consider the following examples:

•Assume that the Windchill installation creates the site context and has a child organization context that is named Bike Company, and that an administrator (using an out-of-the-box library template) creates a public library context using the following:

○The team is a local team.

○The context is named Sales and is a child of the Bike Company context.

Then the domain hierarchy for the Sales library is as follows:

From within the Policy Administration utility, the hierarchy is shown as follows:

/ (Site)

|-Default (Organization Bike Company)

|--PDM (Organization Bike Company)

|---Default (Library Sales)

|-Private (Organization Bike Company)

|--System (Library Sales)

•Assume that the Windchill installation creates the site context and has a child organization context that is named Bike Company, and that an administrator (using an out-of-the-box product template) creates a product context using the following:

○The team is a shared team named Design.

○The context is named Tire and is a child of the Bike Company context.

Then the domain hierarchy for the Tire product is as follows:

From within the Policy Administration utility, the hierarchy is shown as follows:

/ (Site)

|-Default (Organization Bike Company)

|--Design (Organization Bike Company)

|---Default (Product Tire)

|-Private (Organization Bike Company)

|--System (Product Tire)

•Assume that the Windchill installation creates the site context and has a child organization context that is named Bike Company, and that an administrator (using an out-of-the-box project template) creates a public project context using the following:

○The team is a local team.

○The context is named Super Bike and is a child of the Bike Company context.

Then the domain hierarchy for the Windchill ProjectLink Super Bike project is as follows:

From within the Policy Administration utility, the hierarchy is shown as follows:

/ (Site)

|-Default (Organization Bike Company)

|--Project (Organization Bike Company)

|---Default (Project Super Bike)

|-Private (Organization Bike Company)

|--System (Project Super Bike)

•Assume that the Windchill installation creates the site context and has a child organization context that is named Bike Company, and that an administrator (using an out-of-the-box project template) creates a private project context using the following:

○The team is a local team.

○The context is named Future Bike and is a child of the Bike Company context.

Then the domain hierarchy for the Windchill ProjectLink Future Bike project is as follows: