Working With the Initial Organization Context
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.
After installation, every Windchill solution has an installed top-level site context, and an initial organization context. Site context activities are performed from Site 
; organization context activities are performed from Organizations 
.
; organization context activities are performed from Organizations .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.
 | With Windchill PDMLink, the installer can install demo data. As part of the demo data installation, the Demo organization context is created and the Demo user is created as the organization administrator. As is the case for all organization contexts, the Demo organization context inherits rules and data from the site context, but the Demo organization does not have the same owning organization as the site context or the initial organization context. |
You can create additional organization contexts. PTC recommends that if you are considering using multiple organization contexts in the future, you should create at least one additional organization context in which to create your products, libraries, projects, or programs, rather than creating them within the initial organization context. This allows you to add additional organizations (participants and contexts) without having to restructure your administrative data so that members of one organization cannot see data from another organization.
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.