Coordinate sequential and parallel Change Tasks

Change Tasks, or CTASKs, divide implementation into concrete pieces of work. Each task has its own assigned team and optional individual, allowing several teams to contribute without changing ownership of the parent Change.

Before you start

Review the parent Change's approval status and plans. Decide which tasks depend on earlier work and which are genuinely independent. Parent Change editing and CTASK editing are different permissions: task access follows the task's own assigned team.

Steps

1. Open the Change's task section or ExpertHub → Change Tasks.
2. Add a task with a concrete execution step and expected outcome.
3. Assign an implementation team and optionally an individual.
4. Set task order. Two non-parallel tasks cannot share the same order.
5. Mark a task parallel only when it may run independently of earlier tasks.
6. After the parent Change is authorized (or during an eligible Emergency break-glass window), progress an eligible task from New to In Progress, then Closed. Use Cancelled where appropriate.
7. For sequential work, confirm all earlier-order tasks are Closed or Cancelled before progressing the next task. Review the blocked condition in the task overview.
8. Record progress, results and deviations in the Change's worknotes, and verify the real technical outcome before final Change closure.

Expected result

Teams can see who owns each execution step, which work is blocked and what may proceed independently. The parent Change remains the coordinating record.

Sequential dependencies

A non-parallel task remains blocked while any earlier-order task in the same Change is not Closed or Cancelled. The overview calculates and displays that condition. Parallel tasks are exempt from sequential blocking; they still require Change authorization or a valid Emergency break-glass execution exception.

For example, backup at order 1 precedes deployment at order 2, followed by validation at order 3. Deployment waits for backup to be Closed or Cancelled, and validation waits for earlier-order work. A separate communications task can be parallel if it is genuinely independent.

Before approval

CTASKs normally remain New before Change authorization; an active scoped Emergency break-glass exception is the narrowly defined alternative. The Change creator, administrator or Change Manager may cancel a task before approval, but cannot bypass the progression lock to execute it. Change Managers can delete CTASKs according to their role permissions.

Important behaviour

The task's assigned team may differ from the parent Change's team. A parallel flag bypasses sequential blocking, not authorization. Closing CTASKs does not prove that an external release, test or deployment succeeded: confirm the actual result before closing the Change.

Tasks generated by a Standard Change Model

An approved Standard Change Model may define up to 100 reusable CTASK blueprints with team, order and parallel/sequential behavior. Creating a Standard Change automatically generates numbered NEW tasks. These model-derived tasks have immutable provenance and cannot be deleted from an individual Change; authorized operators can reorder them for that Change, and can add additional tasks. Additional non-model tasks can be deleted while NEW by the creator, Change Manager or administrator.

Emergency break-glass task boundary

A break-glass exception lasts two hours and cannot be renewed. During that window only the recorded scope is permitted. After expiry no new execution may start; tasks already started may record completion or cancellation. Record the execution outcome and independent review before Change closure.

Related guides