Skip to main content
Tasks make the next piece of work visible and accountable. They are useful when a request needs a person, a due date, a priority, a discussion, or a clear completion signal. They do not replace the underlying service record, and completing a task is not automatically a formal approval, signature, or final policy decision. For CSR-2026-00042, the Service Manager owns the request. The Registry Officer is assigned the completeness task, the Field Inspector contributes inspection evidence, and the Records Officer is informed when the evidence packet is ready. The final reviewer uses the configured record and signature workflow to decide the request.

​
Goal

Use Tasks to assign and track work clearly while preserving the request record as the source of truth for service status and formal decisions.

​
Understand task roles

Task roles answer different questions. Assign only the roles that create a real responsibility. Do not add everyone as an assignee. One clearly named next owner is more useful than a long list of people who assume somebody else will act.

​
Collections, views, and grouping

Tasks can be organized in personal or shared collections. Personal collections help a member organize their own work; shared collections support a team queue. The Tasks landing page also provides common views such as all work, assigned to me, owned by me, contributing to, informed about, created by me, and related to me. Inside the workspace, use the view and grouping that answers the operational question: Filters help a person find work; they do not change the task’s access rules. A missing task may be filtered out, belong to another collection, be outside the member’s scope, or not involve that member in the selected role. On a board, collapse one column or use Collapse all when you need to scan headings without rendering every card. The collapsed state is a view preference, not a task-status change, and a board with no compatible columns can leave collapse unavailable. Expand the relevant column before concluding that work is missing. Built-in task boards can also show eligible AI suggestions in their dedicated suggestion column; those cards remain proposals until an authorized reviewer accepts them.

​
Create an accountable task

  1. Open the request or task collection that owns the work.
  2. Write a title that names the outcome, not only an activity. For example: Verify address evidence for CSR-2026-00042 rather than Check request.
  3. Link the task to the service request, inspection, project, or other approved context.
  4. Assign one accountable person for the next action and add an owner if the service policy distinguishes ownership from execution.
  5. Add contributors and informed members only when they have a real duty.
  6. Set a due date and priority that match the service target. A task without a due date can still be legitimate, but it should not hide an urgent obligation.
  7. Select the approved task status/template and record enough context for a colleague to understand the request without guessing.
  8. Save, then test how the task appears in the assignee’s Home and task list.
Expected result: the assignee can state what to do, why it matters, by when, and which request/inspection the result must update.

​
Review task suggestions extracted from email

KayanOS can turn a clear action item in an analyzed email into a Pending task suggestion. This is automatic extraction, not automatic approval: pending suggestions stay out of normal task lists and workflows until an authorized member accepts them. Open AI suggestions under Tasks to review Pending work. Rejected suggestions remain in Rejected so permitted reviewers can inspect the history and restore a suggestion when appropriate. Each suggestion is tied to the exact message that supplied the action. Role routing is limited to normalized From, To, and Cc addresses on that message; participants from other messages in the thread, Bcc recipients, and addresses invented by analysis are outside the boundary. AI proposals win only when they stay inside that set. If a role has no valid proposal, KayanOS uses From for owner, To for assignees, and Cc for informed. Addresses that match active organization members become internal member participants. Addresses that match an active hosted group address or alias become internal group principals, so the group’s configured selector and access rules govern which group members can see or act on the task. Only source-message addresses with no internal member or hosted-group mapping are shown as External contacts. An external contact is not a member or group assignment, receives no KayanOS access, and receives no task notification. Before accepting, confirm the title, due date, source excerpt, proposed participants, and routing reason. The Accept dialog asks only for:
  • a task type; and
  • one or more collections.
The task-type list is permission-aware: it includes only types that the current member’s derived roles allow them to create. KayanOS repeats that check when the suggestion is accepted, so a stale dialog or direct request cannot turn a suggestion into a restricted task type. A suggestion does not broaden task authority. If the required type is unavailable, ask an authorized task administrator to review the member’s specific task-type assignment or have an already-authorized reviewer accept it; do not grant a broad role only to clear the suggestion. Acceptance initializes the normal task workflow. Edit other details—such as title, description, people, due date, priority, or workflow status—separately in the normal task detail view after acceptance. Reject a suggestion that should not become active work; rejecting retains the review record rather than deleting it. The source email shown on an extracted suggestion is immutable provenance: it remains tied to the exact source message and cannot be removed through the normal unlink action. From an accepted task’s details, a permitted user can search mailbox messages they already may access and add manual email links as supporting context. Manual links are labeled separately and may be removed by a permitted user. Email details show accessible linked tasks across accepted, Pending, and Rejected states and open each one in the correct task or suggestion view.

​
Ask another member for work or review

KayanOS supports task requests to another member. Use this when a colleague must provide an action, clarification, or review that deserves a visible request rather than an informal message.
  1. Open the relevant task.
  2. Choose the member who must respond. You cannot create a request to yourself.
  3. State the exact requested action, the request reference, due expectation, and what evidence or response is needed.
  4. Send the request and confirm that the recipient is appropriate for the task’s scope.
  5. When the response arrives, record the resulting fact or decision on the task and related request.
Use a task request for operational work. Use the configured form/signature workflow when the organization needs a formal approval, acknowledgement, rejection, or signature proof.

​
Create a task from chat without losing context

An eligible nonempty text chat message can seed a task. This is useful after the Service Manager confirms, “Please obtain the corrected location document by tomorrow.”
  1. Open the message action and create the task.
  2. Check the generated title/body and add the correct request or inspection relationship.
  3. Set owner, assignee, due date, priority, and status explicitly.
  4. Save the task, then return to the request record to record the authoritative service outcome once work is complete.
The chat message remains coordination context. The task becomes accountable work. The request/inspection record remains the authoritative service data.

​
Completion, review, and formal decisions

Use a task status to show that an action is pending, in progress, blocked, returned, or complete according to the configured task lifecycle. Before marking a task complete, check the evidence and the related record:
  • Is the required evidence attached in the approved location?
  • Did the assignee record the finding on the request or inspection?
  • Does the request status now need to change?
  • Is a reviewer decision or signature required separately?
  • Does the citizen communication still need a drafted or sent outcome?
For a formal service decision, link to Form actions, logic, and signatures. Do not describe a completed task as a signed approval unless the configured workflow records that proof.

​
Availability and permissions

Task visibility and mutation follow the organization’s role/scope design. A member may see a task in a shared collection yet be unable to update a related request, or may update an assigned task but not change the status of a request outside their service scope. Test access at the task and related-record level. When work is missing, check in this order:
  1. selected collection and active filters;
  2. assigned/owned/contributing/informed/related role;
  3. task status and due-date grouping;
  4. member access to the task and its linked record; and
  5. whether a different team owns the next action.

​
Safe testing

Create one controlled task for CSR-2026-00042. Assign it to a Registry Officer, make the Field Inspector a contributor, and make the Records Officer informed. Verify each role-specific view, then test a request to another member. Use a synthetic message to create a task from Chat. Finally, confirm that closing the task does not change the request’s formal decision unless the authorized reviewer performs the required workflow.

​
Troubleshooting

KayanOS task for a representative citizen-request escalation.