Status templates and todo - KayanOS Documentation

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

Name the business owner for the workflow and the technical administrator who can publish it.
List the entry state, every expected next state, the person accountable at each state, the required evidence, and the customer-facing meaning where applicable.
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.
Decide which users may trigger each transition. Role access and record scope still apply even when a transition exists in the graph.
Build and test the change on controlled non-production work before publishing it to a live service.
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:

Create the template name and description so administrators understand the service it governs.
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.
Select exactly one default status. Test that a new controlled work item starts where the team expects.
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.
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.
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

Assign accountable operational work in Tasks and approvals.
Build decision evidence in Form actions, logic, and signatures.
Test access to transitions in Roles and scopes.
Report status-based workload with Dashboards.

KayanOS status templates for Citizen Service Request work at the Directorate of Citizen Services.

​Goal

​The model: status, category, transition, action

​Before changing a live template

​Organize templates in folders

​Build the Citizen Service Request lifecycle

​Configure todo conventions

​Validate before publishing

​Troubleshooting

​Related guides