b.Set the Set State permission in the /Default domain on the object type in the life cycle state you identified previously.

Managing User Collaboration

User collaboration can be done using a specific Windchill solution and other PTC or third party products or using multiple co-installed Windchill solutions.

Windchill provides the following tools for collaboration:

•Windchill projects that are created using Windchill ProjectLink provide participants with a place in which they can share information. This information can include data that resides in either a Windchill PDMLink or Arbortext Content Manager solution.

•Creo Elements/Pro 5.0 provides users with the ability to share CAD drawings and other design-related information. For administration information, see the

Using PTC Creo Parametric with PTC Windchill guide.

Additional Administrative Groups

The following additional administrative groups are automatically created for all Windchill solutions to help define users for specific administrative activities in your solution:

•Attribute Administrators

•LifeCycleAdministrators

•Replication Managers

•Type Administrators

•WorkflowAdministrators

•Workflow Authors

For example, those users in the Attribute Administrators group can manage the metadata for global attributes. Those users in the LifeCycleAdministrators group become participants in the Default life cycle template, when that template is used.

If Windchill Supplier Management is installed, the installation creates the following administration group:

•Supplier Administrators

For information on Supplier Management activities, see the PTC Windchill Supplier Management Administrator's and User's Guide.

By using the Participant Administration utility, you can add users to any of the administration groups.

Additional types of administrators are available as appropriate for the application contexts within your Windchill solution:

•An organization administrator manages a specific organization.

•A product manager manages a specific product.

•A library manager manages a specific library.

•A project manager manages a specific project.

•A program manager manages a specific program.

•A shared team manager manages a specific shared team, and acts as a context manager for any contexts that use the shared team.

For additional information about administrators, see Establishing Administrators on page 20 .

Post-Installation Activities

Before allowing users to access the Windchill solution, be sure to do the following activities:

•Determine if there are additional organization contexts that you want to create and create them. For more information, see Organizations on page 139

•Determine if additional organization participants are needed and whether or not to allow these organizations to own parts and documents.

By default, all parts and documents are owned by the organization from which they are created. For information on how to set up the ability to choose which organization owns a part or document, see Organizations on page 139

•Add participants to license groups. Currently, the View and Print Only license group is available. For more information, see About the View and Print Only License Group in the Access Control section of the PTC Windchill Specialized Administration Guide.

•Determine whether you want audit reports enabled. For more information see the Auditing help.

3

Contexts – Distributed and

Hierarchical Administration

This section provides the overall details relating to working with contexts. Later sections assume that you have read the information in this section.

59

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.