the rule is applicable to all Requirements objects in that state, even if they arrived at the state through different life cycles. However, each phase of a life cycle must be associated with a life cycle state chosen from among all states defined in the system.

Note

If the domain policy access control rule denies access to a user and if an ad hoc access control rule grants the user access, then the ad-hoc policy is used, that is, the user is granted access. Ad hoc policies overrule and can provide access to a user where the domain policy denied it. For more information, see the access control section of the PTC Windchill Specialized Administration Guide.

As a life cycle administrator, you can create a variety of life cycles. These life cycles, which are stored in the System folder, define the phases and gates associated with various business objects. For the life cycle of each object, you can define the transitions through which the object must move, and the behavior associated with the object while it is in a specific state.

Windchill provides a Default life cycle, with many predefined states, such as In Work, Under Review, and Released.

Before you begin creating life cycles, you should understand life cycle iteration and life cycle roles.

Basic and Advanced Life Cycles

Windchill supports two types of life cycles: basic and advanced. There are major differences between the basic and advanced life cycle that are visible to the user. The main differences are in the setup of the team definitions for an object, in the workflow processes for managed objects, and in the system performance when creating and revising objects. Using basic life cycles provides improved performance for core creation and revise operations.

You can designate whether the life cycle includes certain aspects of a life cycle definition. This is especially useful for team definitions and the use of workflow processes in Windchill.

When you create a basic life cycle, only the life cycle template, state, and transitions are defined. When you create an advanced life cycle, extra capabilities can be defined including phase information, team, and workflow processes.

Note

PTC recommends that you use the basic life cycle for improved performance and scalability.

Any particular context could have a mix of basic and advanced life cycles associated with objects. Ideally, an object is associated with an advanced life cycle only when necessary, such as when you route an object in Windchill ProjectLink.

Any time you need to manage access via life cycle team roles and to drive an object through its life cycle states by a workflow process, use an advanced life cycle.

Basic Life Cycles

When you create a basic life cycle, you define the following:

•The life cycle properties, including name, location, an optional description, the object classes to which the life cycle applies, and whether the life cycle is enabled.

•Phases and gates that define the life cycle.

•Transitions to be defined from the current (selected) state to any defined state within the life cycle template.

The basic life cycle is designed to use the context team defined in any application context. A basic life cycle does not include workflow process definitions and relies on the workflow process definitions with change management, routing, or promotion processes. Use this type of life cycle for most Windchill objects because the basic life cycle provides improved performance during the creation and revision of objects.

When you create an object with a basic life cycle and select a team template, the selection of the team has no effect. Basic life cycles do not utilize teams or workflows.

Advanced Life Cycles

When you create an advanced life cycle, you define the following:

•The life cycle properties, including name, location, an optional description, the object classes to which the life cycle applies, and whether the life cycle is enabled.

•Phases and gates that define the life cycle.

•Roles, such as Reviewer or Workflow Assignee, for each life cycle phase. These roles can be mapped directly to users or user-defined groups, but are most often mapped to team roles or actors.