Task concepts

This page covers the building blocks of a task: its lifecycle, priorities, checklists, and the settings your organisation can configure.

Statuses and lifecycle

Every task moves through a lifecycle described by its status. Statuses are configurable per organisation — you can rename and recolour them to match your team's language — but each status maps to one of a fixed set of categories that the platform uses to drive behaviour:

Because behaviour keys off the category rather than the label, you are free to rename statuses without changing how the platform treats them.

The default statuses are:

• To do (not_started, the initial status)
• In progress (in_progress)
• In review (in_review)
• Completed (done)
• Cancelled (cancelled)

A few rules govern transitions:

• New tasks start in the first active not_started status.
• Marking a task complete moves it to the first active done status.
• Cancelling a task moves it to the first active cancelled status, and is reserved for managers and the task's creator.
• done and cancelled are terminal — a task in either category cannot be reopened or transitioned further.

Priorities and SLAs

Each task has a priority. Priorities are configurable, and each one carries a default SLA (the time within which the task should be completed). The built-in defaults are:

A task's due date is derived from its SLA, and a task is flagged as overdue once its due date passes without completion.

Checklists

A task can carry an ordered checklist to guide structured manual review. Each checklist item has a type — boolean, text, date, currency or number — an optional value, a done state, and its own notes. Checklists are useful for review tasks where a reviewer needs to capture specific answers rather than simply mark the task done.

Notes

Tasks (and individual checklist items) support free-text notes. Notes can be pinned so that the most important context stays at the top, and the order of pinned notes can be arranged.

Configuration

The status list, priority list and SLA mapping are all configurable per organisation, per environment (sandbox and production are configured independently). If you never customise them, the built-in defaults above apply.

References to entities

A task can be linked to an insurance entity through its reference. Supported reference types are:

• policy
• claim
• application
• quote
• complaint

A reference can be resolved from either an entity's UUID or its human-friendly number (for example a policy or claim number). Reference resolution respects the caller's user-group access, so a task can only be linked to entities the user is permitted to see.