Rules for Request Lifecycles

When you apply rules to a request type, you must group its lifecycle states into phases. A phase is a system-defined stage that determines what kind of processing can take place while a request is at that state.

The phases are defined below.

Phase	Description	How Set?	Permitted Tasks
HELD	Specifies the stage in which an originator prepares and holds a request. A held request is not visible to any other users. It appears in the originator's inbox with the status $TO_BE_DEFINED. This phase does not correspond to an actual lifecycle state.	Automatically applies to held requests.	Relate design parts Update attributes
CREATE	Specifies the normal lifecycle states (if any) which precede the ANALYSIS phase.	Automatically applies to new requests.	Relate design parts Relate items as Affected Update attributes Add action descriptions Action
ANALYSIS	Specifies the normal lifecycle states in which you analyze and plan the implementation of the change. Good analysis during this phase ensures that you understand the change and that you identify the dependencies and items that require changing.	Select the normal lifecycle state that signifies the start of the ANALYSIS phase. If you select the first state in the lifecycle, then the CREATE phase does not exist; its activities are merged with those in the ANALYSIS phase.	Relate design parts Relate items as Affected Relate requests Update attributes Add action descriptions Action
WORK	Specifies the normal lifecycle states in which you implement the change. You can work on items that have been related as Affected in this phase. On check in, these items are automatically related as In Response To. If item rules require that a request is specified on check out, and an item has not yet been related as Affected, then Change Manager must relate the item as In Response To in this phase.	Select the normal lifecycle state that signifies the start of the WORK phase. You cannot select a state that precedes the state specified for the ANALYSIS phase.	Relate items In Response To Update attributes Add action descriptions Action
FROZEN	Specifies the normal lifecycle states (if any) which follow the work phase but may precede the final normal state. This phase includes the states in which testing, baselining, and qualification of the software may take place. Consequently, no changes are permitted to any of the relationships, nor to any of the related item revisions. The related item revisions are also frozen by this stage, through baselining and/or actioning. Note: The restrictions on updating relationships do not apply if the user has the CHANGE MANAGER role.	Select the normal lifecycle state that signifies the start of the FROZEN phase. If you select the final normal state, then the FROZEN phase does not exist. The request becomes frozen only when it is closed. You cannot select a state that precedes the state specified for the WORK phase.	Update attributes Add action descriptions Action
CLOSED	Specifies the final normal state. No further changes are permitted.	Automatically applies to the final normal state.	None
REJECTED	Specifies all final states except the final normal state. No further changes are permitted.	Automatically applies to any off normal final states.	None
OFF NORM	Specifies all other states that are not in the normal lifecycle and are not final states.	Automatically applies to all off normal, non-final states.	Update attributes Add action descriptions Action
AN+WORK	A composite phase that specifies all normal lifecycle states between the CREATE phase and the FROZEN phase, as an alternative to assigning separate ANALYSIS and WORK phases. Using this phase works best on small teams, where some implementation may be allowed during analysis. For larger teams or projects, separate ANALYSIS and WORK phases are recommended for more control.	Select the same state for the WORK and ANALYSIS phases.	Relate design parts Relate items as Affected Relate items in Response to Relate requests Update attributes Add action descriptions Action

NOTE A request is described as open when it is in any phase except HELD, CLOSED, or REJECTED.

Parent-Child Rule

In addition to the phases outlined above, you can define a rule regarding parent-child requests. This rule specifies the minimum state that the request (the child) must reach so that the parent request can close. Additionally, the parent request can close if the child document is actioned to the REJECTED phase.

Roles and Permitted Tasks

The tasks permitted in each phase can only be performed by the Dimensions CM users who hold a role on the current state. In the case of the HELD phase, the only authorized user is the originator. If the leader responsibility is enforced, then only the users with the leader responsibility can action the request and update its attributes.

Change Managers have additional permissions. They can relate and unrelate objects at any lifecycle state except the final state, as well as action any request to any of its lifecycle states. They can also reactivate a closed or rejected request by actioning it to a non-final state.

Example: Change Request Phases

The following diagram shows how the normal lifecycle states in a change request (CR) type are mapped to phases:

Analysis phase starts with state: Allocated
Work phase starts with state: Allocated
Frozen phase starts with state: Implemented