Task Lifecycle

Tasks are the primary way CareLaunch tracks work that needs to be done. A task can represent a case review, a follow-up, a form that needs to be completed, a reminder, or a handoff to another system. This page explains the statuses a task can have, how tasks move between them, and who can make those changes.

Statuses

CareLaunch uses the following task statuses. The table lists 12 values, but only 11 are selectable in the task editor; accepted is shown for compatibility but cannot be chosen manually.

Status	Display Name	Description
draft	Draft	Task has been created but is not yet actionable. Used for tasks that are being assembled or are pending additional information.
requested	Requested	Task has been requested and is awaiting acceptance. This is the default status when a task is created through a data import or external API. Also used for scheduled reminder and check tasks.
received	Received	Task has been received by the intended performer but not yet started.
accepted	Accepted	Task has been accepted by the performer and is queued for work.
rejected	Rejected	Task has been declined by the intended performer.
ready	Ready	Task is ready to be performed. This is the default status when a task is created by an automation (for example, a "Create Task" action) or through an integration.
in-progress	In Progress	Task is actively being worked on.
on-hold	On Hold	Task has been temporarily paused.
cancelled	Cancelled	Task has been cancelled before completion. Common when a linked appointment is cancelled.
completed	Completed	Task has been finished. This is typically the final active state.
failed	Failed	Task could not be completed due to an error (for example, a missing appointment reference or a notification delivery failure).
entered-in-error	Entered in Error	Task was recorded by mistake.

Status Flow Diagram

stateDiagram-v2
    [*] --> requested : Data import / external API
    [*] --> ready : Automation or integration

    requested --> in_progress : User starts work (board/UI)
    requested --> completed : Patient completes via portal
    requested --> completed : Late/no-show check resolves
    requested --> cancelled : Linked appointment cancelled
    requested --> cancelled : Appointment not found
    requested --> failed : Missing reference or delivery failure
    requested --> on_hold : User pauses task (UI)
    requested --> rejected : User rejects task (UI)

    ready --> in_progress : User starts work (board/UI)
    ready --> completed : User completes task (UI)
    ready --> cancelled : User cancels task (UI)
    ready --> on_hold : User pauses task (UI)

    in_progress --> completed : User or system completes task
    in_progress --> cancelled : Linked appointment cancelled
    in_progress --> failed : Retry attempts exhausted
    in_progress --> on_hold : User pauses task (UI)

    on_hold --> in_progress : User resumes task (UI)
    on_hold --> cancelled : User cancels task (UI)

    completed --> in_progress : User reopens (subtask toggle)
    cancelled --> [*]
    failed --> [*]
    entered_in_error --> [*]

    state "draft" as draft
    state "requested" as requested
    state "received" as received
    state "accepted" as accepted
    state "rejected" as rejected
    state "ready" as ready
    state "in-progress" as in_progress
    state "on-hold" as on_hold
    state "cancelled" as cancelled
    state "completed" as completed
    state "failed" as failed
    state "entered-in-error" as entered_in_error

How Tasks Are Created

Data import or external API

When a task is created through a data import or an external API connection, it is created with the status requested unless a different status is provided. Default values are applied for intent, code, and authored-on timestamp.

Automations and integrations

When an automation uses a Create Task action, or when a task is created through an integration such as AWS Connect, it is created with the status ready unless the automation template specifies otherwise.

The task is linked to the resource that triggered it and to the patient it relates to.

Manual Status Changes

A user can change a task's status through the admin UI — for example, in the task edit dialog, in a task list, or by dragging a card to a different column on a board.

When a status is changed through the UI, the platform records a status-history entry so you can see when the change happened.

Automated Status Changes

Several platform processes can change a task status automatically:

Patient portal callback

When a patient completes a task action through the patient portal, the task is set to completed.

Late reminder check

A scheduled check verifies whether a patient joined an appointment before it started. If the patient joined, or if the reminder type is disabled, the check task is set to completed.

No-show check

A scheduled check evaluates whether a patient attended an appointment. Based on the outcome, the check task is set to completed, cancelled, or failed.

Appointment cancelled

When an appointment linked to a task is cancelled or dismissed, related reminder and check tasks are set to cancelled.

Appointment not found

If a scheduled check cannot find a valid appointment, the related task is set to cancelled.

Missing reference or delivery failure

If a check task cannot proceed because it is missing an appointment reference, or if a Concierge action fails, the task is set to failed.

Notification retry

When an initial notification fails to deliver, the platform creates a retry task. The retry task moves through requested → in-progress → completed, failed, or cancelled depending on the result.

Subtask toggle

When a user marks the final subtask complete or incomplete in a task list, the parent task toggles between completed and in-progress.

Business Status (Workflow-Based Stages)

In addition to the overall task status, tasks that are part of a workflow use a business status to track progress through workflow-defined stages.

• Board columns can be configured to group tasks by business status.
• Business statuses are defined by the workflow's actions (for example, "Registered", "Records Collection", "In Review", "Completed").
• When a task belongs to a workflow, the board's status dropdown shows the workflow stages instead of the FHIR statuses.
• Business status changes made through the UI are recorded in the status history.

For more information on workflows, see Workflows.

Status History

Status changes made through the admin UI are recorded in the task's statusReason field, which stores the previous and new statuses along with the timestamp of the change. This gives you an audit trail of manual status updates.

System processes (such as appointment cancellation or notification retries) may overwrite statusReason with a plain-text note like "Appointment cancelled". Because of this, the status history is most reliable for changes made by users in the UI.

Automations

Tasks participate in the CareLaunch automation engine in two ways.

Tasks created by automations

The Create Task automation action creates tasks when a trigger condition is met. Common triggers include:

• Resource Creation — for example, when a patient is created.
• Resource Update — when a record is updated.
• Resource Delete — when a record is removed.
• Scheduled (Recurring) — runs on a repeating schedule.
• Scheduled (One-Time) — runs once at a scheduled time.
• Manual — triggered by a user.

The default status for a task created by an automation is ready unless the automation template specifies otherwise. The template can pre-populate fields such as status, code, description, owner, due date, and linked questionnaires. Automations can also create subtasks as part of a workflow.

Automations triggered by task changes

Task creation and updates can themselves trigger automations:

• Resource Creation trigger fires when a new task is created.
• Resource Update trigger fires when a task is updated, including status changes.
• Resource Delete trigger fires when a task is deleted.

Automations can filter on task fields (code, status, owner) to decide which task events trigger downstream actions.

Concierge Service Integration

The Concierge service maps task statuses to internal action states:

Task Status	Action Status
requested	pending
completed	executed
cancelled	cancelled
failed	failed
All others	pending

Reminder and check tasks

The platform automatically creates and manages tasks for appointment-related workflows:

1. Reminder tasks — Created with status requested for upcoming appointments. Cancelled automatically if the appointment is cancelled.
2. Late reminder check tasks — Verify whether a patient joined before the appointment. Auto-resolve to completed, cancelled, or failed based on appointment state.
3. No-show check tasks — Evaluate post-appointment attendance. Auto-resolve based on whether the patient attended.
4. Notification retry tasks — Created when initial notification delivery fails. Progress through requested → in-progress → completed/failed/cancelled.

Access Control

Action	Who Can Perform
Create	Admin users, automation engine, patient portal (via callback)
Read	Platform Admin, Organization Admin, Instance Admin, assigned practitioner
Update status	Platform Admin, Organization Admin (via UI), automation engine, system processes
Complete (portal)	Patient (via callback with a valid envelope)
Delete	Platform Admin, Organization Admin

Related Documentation

• Tasks — task creation, types, and management overview
• Boards — visual kanban-style task management
• Workflows — configure task workflow stages and business statuses
• Automations — create and manage tasks automatically
• Service Request Lifecycle — related resource lifecycle documentation