Your Windchill environment consists of a set of containers that hold all of the administrative areas (known as domains), rules, and data that make up the context from which Windchill users work. Although the underlying code refers to containers, the term Context is used throughout the user interface to identify where in the framework specific rules, domains, and data reside. Since Context is the label you see in the interface, this topic collection uses the term context (rather than container) so you can make the connection with the user interface. Unless you are working with the code, you can assume that context and container refer to the same thing.

The contexts are set up in a hierarchy so that the rules and data created in one context can be available to child contexts and the domains in one context can have child domains in a child context. The child domains inherit information from ancestor domains.

The organization context is a child of the site context. The context name of the initial organization context is the organization name that was entered during installation. For example, assume that the organization name is Org1, then the following context hierarchy is established:

In this example, the Org1 organization context inherits rules and data from the site context.

Both the site and the initial organization contexts have the same owning organization participant (type WTOrganization). This becomes important if you want to segregate some of the objects created in an organization context from other contexts. The term participant is introduced here and used throughout Windchill as a way of categorizing Windchill objects that identify users, groups, and organizations. The organization participant created in the installation process becomes the owning organization for some of the objects created in both the site and the initial organization contexts. For example, subtypes are associated with the owning organization. Therefore, any subtypes you create from within the initial organization context become site-level subtypes because the owning organization is the same.

To have subtypes created in an organization context that do not be come available as site-level subtypes, the context from which the subtypes are created cannot be the initial organization context created during the installation.

You must set the organization administrator for each organization context. For more information on how to do this, see Establishing Administrators.

For information about creating and using organization contexts, see Organizations.