> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kayanos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Status templates and todo

> Design published status graphs and task conventions that make the next service action clear without treating a task completion as a formal decision.

A status template is a controlled graph: it contains statuses, one default status, and permitted transitions between them. It gives a service or task workflow a shared language for what can happen next. A task helps a person complete work; it does not by itself sign, approve, or close a citizen-service decision.

For the Directorate of Citizen Services, use a small lifecycle that shows who owns the next step and what evidence must exist before a transition. Keep the service record’s formal decision controls separate from everyday task progress.

## Goal

Create and publish a reviewable status template, configure task terminology around it, and test both the allowed and disallowed paths before a live team depends on it.

## The model: status, category, transition, action

| Term              | Meaning                                                                                          | Directorate example                                                       |
| ----------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------- |
| Status            | A named state in a workflow                                                                      | Received or Decision review                                               |
| Category          | The broad work state assigned to a status: **todo**, **in\_progress**, or **done**               | Received is todo; Inspection scheduled is in progress; Closed is done     |
| Default status    | The first status applied when the configured workflow starts                                     | Received                                                                  |
| Transition        | A permitted directed move from one status to another                                             | Completeness review → Ready for inspection                                |
| Transition action | A configured follow-up that runs as part of an allowed transition where the template supports it | Create a controlled follow-up or require the configured workflow evidence |
| Draft content     | The design being edited                                                                          | A proposed new transition not yet relied on by users                      |
| Published content | The released graph used by configured work                                                       | The approved lifecycle currently in use                                   |

Statuses do not replace data fields. Put the actual inspection finding, decision reason, document, or citizen communication outcome on the record or controlled form. A status tells people where the work is; it is not all of the evidence for why it is there.

## Before changing a live template

1. Name the business owner for the workflow and the technical administrator who can publish it.
2. List the entry state, every expected next state, the person accountable at each state, the required evidence, and the customer-facing meaning where applicable.
3. Identify every entity, task type, form action, dashboard, document, or automation that reads the existing status values. Renaming or removing a state can affect filters, calculations, templates, and reports.
4. Decide which users may trigger each transition. Role access and record scope still apply even when a transition exists in the graph.
5. Build and test the change on controlled non-production work before publishing it to a live service.
6. Prepare a rollback: retain the known published graph and a note describing how active records will be handled if a proposed transition is withdrawn.

Do not edit a live lifecycle merely to resolve one stuck request. Diagnose that record’s scope, required evidence, or missing transition first.

## Organize templates in folders

Use status-template folders to organize administrative configuration by service, directorate, or lifecycle family. Create folders and nested subfolders, open them through the breadcrumb path, and create or import a template into the current folder. Move templates or folders with the move action or supported drag interaction. Folder placement changes where administrators find the template; it does not change the template’s ID, publication state, references, or permissions.

Before deleting a folder, read the confirmation counts. An empty folder can be deleted directly. For a folder containing templates or subfolders, deliberately choose whether to move its contents to the parent or delete the complete contained tree. Never use folder deletion as a shortcut for retiring a live workflow: inventory entity/task references and preserve the published lifecycle under normal change control first.

## Build the Citizen Service Request lifecycle

Open **Administration → Status templates and todo** and create or edit the template. Build a small graph before adding optional branches.

| Status               | Category     | Accountable next responsibility                           | Minimum evidence before leaving                                  |
| -------------------- | ------------ | --------------------------------------------------------- | ---------------------------------------------------------------- |
| Received             | todo         | Registry Officer checks intake                            | Required intake values and attachments recorded                  |
| Completeness review  | in\_progress | Registry Officer confirms or returns missing information  | Completeness outcome recorded on the request                     |
| Ready for inspection | todo         | Service Manager allocates field work                      | Owner/assignee and service location confirmed                    |
| Inspection scheduled | in\_progress | Field Inspector prepares/attends the visit                | Event/inspection context and required preparation recorded       |
| Decision review      | in\_progress | Authorized Reviewer checks evidence                       | Inspection result and required documents available               |
| Closed               | done         | Service Manager confirms no operational follow-up remains | Final outcome and required communication/retention step recorded |

Configure these elements in order:

1. Create the template name and description so administrators understand the service it governs.
2. Add each status with an approved title, optional description/icon/color, and the correct category. Categories affect how tasks and boards summarize work; they do not grant permission.
3. Select exactly one default status. Test that a new controlled work item starts where the team expects.
4. Draw the allowed transitions. Keep return/rework paths explicit—for example, Completeness review can return to Received or a defined missing-information state if the policy needs that distinction.
5. Configure an allowed transition’s follow-up action only when the service owner understands its side effect. An action may create or change related work, so test it as carefully as the status move itself.
6. Save the draft, review the graph with the service owner, then publish the approved content.

The editor keeps draft and published content separately. Do not assume an unsaved or draft-only graph changes live work. Likewise, do not publish a graph solely because it looks visually complete; verify the actual transitions and roles.

## Configure todo conventions

Tasks can use collections, categories, types, priorities, assignees, owners, contributors, informed members, due dates, and a configured status lifecycle. Use task settings to make work clear, not to recreate the service record.

For the Directorate:

* Use a task title that names the outcome: **Verify address evidence for the request**, not **Check request**.
* Assign one next actor; use owner, contributor, and informed roles only when they have distinct responsibilities.
* Use due dates and priority for service targets, not as a replacement for the request’s legal/business status.
* Use personal collections for individual organization and shared collections for a legitimate team queue.
* Record the authoritative result on the request or inspection. Closing the task only shows task progress unless a configured formal form/action/signature path records the decision.

Task status templates, categories, and types should change under the same review discipline as a service lifecycle: understand active use, make one controlled change, test it, and communicate it.

## Validate before publishing

| Test                   | Expected result                                                                                         |
| ---------------------- | ------------------------------------------------------------------------------------------------------- |
| Default status         | A new controlled item receives the approved first status                                                |
| Allowed transition     | Authorized member moves a record along the graph and the configured result/evidence appears             |
| Disallowed transition  | The member cannot jump from Received directly to Closed when no such transition is published            |
| Scope boundary         | A member with a valid transition but no update access to the record cannot use it outside their scope   |
| Rework path            | Returned work follows the explicit return transition without losing the record’s evidence               |
| Task boundary          | Completing a task does not create a formal decision unless the configured decision workflow performs it |
| Dashboard/filter check | Status-based views show the expected category/status after the test                                     |

Use a non-production request and synthetic evidence. Keep a copy of the test graph and results in the change record.

## Troubleshooting

| Symptom                                     | Check first                                                                  | Safe response                                                                           |
| ------------------------------------------- | ---------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| A status does not appear in live work       | Draft versus published content, template assignment, and page refresh        | Publish only after review; verify the configured record/task actually uses the template |
| A user cannot move to a visible next status | Transition exists, update verb, record scope, and required form/action state | Correct the smallest missing condition; do not grant broad administration               |
| A record is stuck                           | Current status, permitted outgoing transitions, missing evidence, and owner  | Use an approved rework/exception path; do not edit database values or invent a status   |
| A dashboard count changed after publish     | Status categories, filters, and active records                               | Review the graph/category mapping and record the reporting impact                       |
| Task completion was treated as approval     | The decision workflow was not configured or not used                         | Record the decision through the approved form/action/signature path                     |
| Delete is unavailable                       | Template delete permission or active references                              | Keep the template, retire its use through change control, and resolve references safely |

## Related guides

* Assign accountable operational work in [Tasks and approvals](/work/tasks-and-approvals).
* Build decision evidence in [Form actions, logic, and signatures](/build/form-actions-logic-and-signatures).
* Test access to transitions in [Roles and scopes](/admin/roles-and-scopes).
* Report status-based workload with [Dashboards](/build/dashboards).

![KayanOS status templates for Citizen Service Request work at the Directorate of Citizen Services.](https://kayanos.app/docs-images/en/admin/status-templates-and-todo.png)