Task Managementlifecycle

Statuses, Reassignment & Failure

How do task statuses, reassignment, and failure actually work?

Task statuses come from configurable values and change under granted permissions, with percent complete and the actual date recorded as work moves. Reassignment is an explicit grant — allowed by the assigner, exercised with notes — and failure is a documented branch, not a deleted row.

The sequence

4 steps
  1. Task is created and assigned

    The record opens with its assigner, assignee, dates, and priority, and appears in both parties’ task lists.

  2. Status moves under permission

    Holders of the granted permission update the status from configured values, with percent complete tracking progress.

  3. Reassign where allowed

    If may-reassign was granted, the assignee hands the task to another employee with notes; may-reassign-again governs further hops.

  4. Complete or fail

    Completion records the actual date; failure records a description with documents, and the task stays in the register either way.

How it works

Status values are configurable lookup items rather than a fixed hard-coded set, and updating a task’s status is a permission-gated action tied to the task-manager resource. Percent complete tracks progress on the record, and completion writes the actual date next to the original due date.

Reassignment is controlled by three explicit flags: the assigner decides whether the assignee may reassign, the assignee reassigns to a chosen employee with reassignment notes, and a may-reassign-again flag controls whether the chain can continue. A task can also carry a monitoring flag, keeping an observer attached without transferring ownership. The flow view lays out the task’s history so the path from creation to the current holder is readable.

The failed branch mirrors the project side: a task is set to failed with a failure description, failure documents attach as evidence, and the record remains in the register. Deletion is guarded — a task with children is checked before it can be removed.

Worth knowing

  • Configurable status valuesStatuses are lookup-driven per organization, so the lifecycle vocabulary matches how the business actually names its stages.
  • Explicit reassignment grantsMay-reassign, reassign-to with notes, and may-reassign-again are separate recorded flags, not an open transfer button.
  • Task flow historyThe flow view shows the task’s progression, so who held it and what changed is read from the record, not reconstructed.
  • Documented failed branchFailed tasks keep a failure description and attached documents instead of being deleted or relabeled.
  • Guarded deletionA child-check runs before a task can be removed, protecting hierarchies from orphaned subtasks.

See statuses, reassignment & failure running in continON.

A guided walkthrough on a sanitized demo tenant — this capability inside its module, on the shared platform.