Contexts—An Administrative Overview
Windchill contexts provide the framework for collecting and finding related information. The set of contexts in your Windchill solution have a hierarchical relationship. The following depicts the basic context hierarchy:
The site context can have one or more child organization contexts. An organization context can have one or more child application contexts.
Application contexts include:
Products
Libraries
Projects
Programs
Data, such as template files, can be distributed among the contexts. For example, you can define general document templates, such as those used for presentations or memos, at the top level of the hierarchy (in the site context). The document templates are available to all contexts. Then you can define progressively more specific templates at each layer in the hierarchy, such as in an organization context or a library context. In a child context, you can also define templates with the same name as those templates in a parent context so that the templates in the child context can override and be used in place of templates in a parent context.
With distributed administration, application context administrators are responsible for their own administrative tasks. So, for example, each product, library, project, and program can have its own administrators (called product, library, project, and program managers). Additionally, if you are using shared teams in context teams, the shared team manager (established in the shared team) becomes the context manager for each application context that uses the shared team. This allows you to easily assign administrative duties for multiple contexts to one or more individuals.
To support distributed administration, the administrative utilities are context aware. For example, opening the Policy Administration utility in the context of a library initially displays the domains that are in the library context and the domains that are ancestors of the library context domains. Having context aware utilities allows the delegation of administrative duties to users who are recognized as application context managers.
With hierarchical administration, contexts inherit administrative items from parent contexts (or, in the case of policies, from parent domains). Administration performed at the level of a parent context is applicable to all of its child contexts. Except for policies, a child context can choose to override the administrative items of its parent contexts. For policies, rules from all parent domains are merged with the rules in a current domain to form the policy for the current domain. For more information about policies, see Administering Domains and Policies.
In general, always think of performing administration duties from within a context, as follows:
Site administrators can create, modify, delete, and view administrative items in the site context.
Organization administrators can create, modify, delete, and view administrative items in the given organization context. They can generally view and override administrative items defined in the site context.
Application context managers can create, modify, delete, and view administrative items in the given application context. They can generally view and override administrative items defined in the parent organization context and the site context.
Site and organization administrators can administer child contexts; however, they do so by going into the child context and performing their administrative duties there.
* 
Windchill users generally perform their activities within an application context, rather than in an organization or site context.
Non-administrative Windchill users generally do not create, modify, or delete administrative items; however, they may have visibility to, and are affected by, the following administrative items:
The administrative items that are defined in a given application context.
The administrative items that are defined in the parent organization and site contexts, but not overridden in the application context.
Was this helpful?