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 stepsTask is created and assigned
The record opens with its assigner, assignee, dates, and priority, and appears in both parties’ task lists.
Status moves under permission
Holders of the granted permission update the status from configured values, with percent complete tracking progress.
Reassign where allowed
If may-reassign was granted, the assignee hands the task to another employee with notes; may-reassign-again governs further hops.
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.
What this touches
- Identity & Access
Status updates, reassignment, and deletion sit under permission resources granted through positions. - Project Management
Status and percent complete roll up into project progress, and failed tasks feed the project’s failure record. - Document Management
Failure documents and task files are stored through the shared document layer. - System Administration
Status values are maintained as configurable lookup items.
See statuses, reassignment & failure running in continON.
A guided walkthrough on a sanitized demo tenant — this capability inside its module, on the shared platform.

