Role Mappings

Advanced life cycles can have a role associated with a particular life cycle phase. When an object is promoted to the phase in the life cycle, the role is assigned to a participant (user, group, or organization). A role mapping is resolved in one of several ways:

•You can directly map life cycle roles to users, user-defined groups, organizations, or other roles. However, since organizations generally want to define only a small number of life cycles, it is not often practical to map life cycle roles directly to participants. Using life cycles and teams together allows role participants to be identified when the phase is reached, rather than making this mapping an explicit part of the life cycle definition.

•You can map life cycle roles to team roles. When the phase is reached, the role is resolved according to the team role mapping. For example, the life cycle role Promoter could be mapped to the team role Team Leader, and the life cycle role Promoter would be resolved at runtime according to the Team Leader role, as mapped in the team.

•You can map a life cycle role to an actor. That is, you can map a role to someone who performs a specific action within the context of the business object. When the phase is reached, this role is then resolved to the participant who created the object with which the life cycle is associated. For example, you could assign the Creator actor to the Submitter role for a given life cycle phase. For that phase, the user who created the object would be assigned the Submitter role at runtime. If the Submitter role is defined in the team, it resolves to the team’s Submitter role.

Associating Life Cycles with Object Types

You can associate object types with life cycles using object initialization rules.

For more information about using object initialization rules to set an object’s life cycle, see the object initialization rules help.

Note

If you create a type and associate it with a default routing life cycle, there may be problems when users create documents using templates created with the type. The default routing life cycles start automatically, so when the user tries to create from a template using one of these life cycles and selects the Check Out and Download action, the checkout and set state (life cycle) gets caught in a race condition. This can cause two outcomes:

•The set state fails; the user has a checked-out document that is In Work, and the life cycle does not happen.

•The set state succeeds and the user has a checked-out, newly-created document that has been immediately routed for review.

PTC recommends you create your own routing life cycle that would contain a specific Submit task later in the process, not an automatic Submit upon creation.

Defining Life Cycle Access Control Rules

The following figure is an example of the Access Control tab.

When creating or editing an advanced life cycle template, you can specify ad hoc access control rules that will apply to the object when it is in the selected life cycle phase. When the object moves to the next life cycle state, the permissions may change or be removed, depending on the access control set for that state. Use the Access Control tab to select permissions for each role.

For more information about the Access Control tab, see the life cycle help. For more information about access control, see the access control section of the PTC Windchill Specialized Administration Guide.

All roles are automatically given Read permission, so the associated participants can access their tasks and view the object. By default, submitters are automatically given Modify permission so they can submit the object for promotion as part of editing it; however, you can change this at your site.

For each role, you can also select one or more of the permissions described in the access control section of the PTC Windchill Specialized Administration Guide.

Associating a Workflow Process with Phases and Gates

Note

This section applies only to advanced life cycle templates.

By default, all advanced life cycles have predefined workflow processes associated with the phases and gates.

When a business object reaches a specific state, the workflow process associated with that state will be automatically initiated and the business object will forwarded through the workflow process.

The workflow process that moves objects through the associated phases and gates is separate from the life cycle of the object. You can manage one or more objects with a workflow process.

To change the workflow process that is associated with a phase or a gate, modify the following properties in the wt.properties file:

•wt.lifecycle.defaultPhaseProcess

•wt.lifecycle.defaultGateProcess

As shown in the following figure, the Submit process is automatically associated with the In Work phase. The Review process is associated with the gate by which an object moves from In Work to its next phase.

Note

Use Latest Iteration is selected, so the most recent iteration of the workflow process template is used at instantiation. If this check box is cleared, the specific iteration selected is used, even if it is not the most recent.