Deafualt behavior change tasks in change workflow

[Marco Jansen]

Dear fellow process managers,

In my work in Change management ihave noticed some inconsistent behavior in the use of change tasks. In certain occasions tasks are set top open when a change status is changed from authorized to scheduled. The status changes is triggered by approving the change during a CAB meeting. In other occasions the tasks are kept in pending state. Can anyone explain what the default behior would be for change tasks. 

I think a task in a normal change would not be set to open as long as this si done manually by an engineer. It is strange that a change task is progressed by a system trigger to open when a change is moved to schedule state.

Please help me on this,

Marco Jansen

[Michael Fry1]

Baseline, you should not get the 2 baseline change tasks until the Implement button or Implement state is selected.

[Sebas Di Loreto]

The way it works out of the box is that when the (normal) change is fully approved during the AUTHORIZED state, it moves to SCHEDULED waiting for the assigned_to person to click on IMPLEMENT when the day of the change execution comes. No change tasks have been created yet, unless they were created manually during the ASSESS (planning) stage....

When the IMPLEMENT button (ui action) is clicked then the change moves to the implement state and two out of the box change_tasks are created. One is type=implementation and the other is type=testing. This is done in conjunction of two change normal workflows.

Type "workflow editor" on the left nav, then search for "change request - normal" and click on both entries.