Review and Close a Task
In LadVen OS, closing a task means the result has been checked, the definition of done has been met, and no further action is needed in this task. This is not a formal status change, but an acceptance point: participants understand what was accepted, where the result is stored, and why the task is no longer in progress.
Good closing protects the business from two problems: unfinished work is not treated as accepted, and new obligations do not get lost in comments on an already closed task. If a new request appears during acceptance, record it explicitly: return the current task to rework, create a related task, or explain why the new request is outside the result.
Basic route: the assignee shows readiness, the result is reviewed, and the decision either accepts the task, returns it to rework, or moves new scope into a separate task.
Good Practice
Do not close a task immediately after a “done” message. First check the result, files, comments, completed checklist items, spent time, and open questions. If the work requires acceptance, the assignee first finishes their part or sends the task for review, and the requester accepts the result or returns the task with a clear comment.
Change the status only after there is a clear result or a clear reason for return. If a correction is needed, describe it in a task comment so the decision stays in the working context instead of disappearing in a private chat.
For a manager, task closing is not only a “done” mark. It is control over deadline, result, risks, and effort. Before final closing, it should be clear what was accepted, what was not accepted, which new obligations appeared, and where they will be handled.
Task statuses
| Status | What it means | When to use |
|---|---|---|
| New | The task has been created, but work has not started yet. | After task creation or return to the start state if the assignee has not taken it into work yet. |
| In progress | The task is being performed. | When the responsible person has started work, is clarifying details, maintaining the checklist, attaching interim files, or logging time. |
| In review | The result is ready and waiting for review. | When the assignee believes the definition of done is met and hands the work to the requester or reviewer. |
| In control | The task is waiting for control or final confirmation. | When a separate control stage is needed: for example, a manager, client, or process owner must confirm the result after review. |
| Completed | The work has been accepted and closed. | When the result has been checked, required materials are attached, questions are closed, and the active timer is stopped. |
| Deferred | The task has been postponed. | When the work is temporarily not relevant, but should not be canceled: the team is waiting for an external event, decision, or new date. |
| Canceled | The task has been canceled. | When the result is no longer needed. Record the cancellation reason in a comment so participants do not continue the work. |
| Not completed | The task was not completed with the needed result. | When the work ended unsuccessfully and this must be distinguished from cancellation or postponement. Specify the reason and next actions. |
Main scenarios
Finish the work
The assignee finishes the work when the result is ready on their side. Before that, compare the result with the description, definition of done, and checklist. If the task does not require a separate review, finishing can lead directly to closure. If review is enabled, the task should move to a state where it waits for review or control.
Before finishing, the assignee checks that:
- the result can be opened, read, launched, or otherwise verified;
- the final version of the file, document, link, or answer is attached to the task;
- required checklist items are checked;
- comments record important decisions, limitations, and what exactly was done;
- the active timer is stopped, and manual time is added if time tracking is needed for plan versus actuals.
Send for review
Send a task for review when the requester or another participant must accept the result. The result must be visible in the task: attach the final file, link, screenshot, document, summary comment, or another verifiable artifact.
A good review handoff comment answers three questions:
- what is ready;
- where to check it;
- whether there are limitations, disputed points, or questions.
If review is a required part of the process, do not bypass it with direct closing. The “In review” status helps separate “the assignee finished” from “the work was accepted.”
Send for control
Control is needed when it is not enough to simply check the result inside the task. For example, confirmation may be needed from a manager, process owner, client, or quality owner. In this case, the task can move to a control state.
Before sending for control, make sure the reviewer will not need to reconstruct the context:
- the description or comments contain the definition of done;
- the final result is attached or linked to the task;
- disputed decisions are described in comments;
- related tasks, CRM entities, or documents are added where they help verify the source of the work;
- the participant who must control the result is added to the task and can see the materials.
Accept the task
Accept a task when the result matches the agreement and does not require rework. If there were acceptance criteria, check against them, not against a general impression.
Before completing the task, check that:
- the result matches the description and expected outcome;
- the task is closed with a clear deadline state: on time, with an explained delay, or with an agreed postponement;
- the required checklist is closed, or it is clear why some items are no longer needed;
- final files and links are available to participants;
- comments contain the final decision if it matters for history;
- the requester, assignee, and co-assignees have no open questions;
- active timers are stopped and spent time is not left in an unclear state;
- plan versus actual time is explainable if the task matters for reporting, a client, or a budget;
- closing does not hide an unfinished stage of the process.
If the result is accepted only partially, do not close the task silently. Either return it to rework with a concrete list of corrections, or create a related task for a new independent result.
Good acceptance records not only the fact that the work is “done,” but also the management outcome: which criteria were used for acceptance, which file version is final, which limitations remain, and where the new scope was moved. If additional requests appear during review, do not close them inside the original task without a trace: create a related task or record why they are outside the current result.
If closing is blocked by a check
Sometimes LadVen OS does not allow a task to be closed or moved to the next stage. This is not a technical issue to bypass; it is a process guard check: the system sees that a required condition for acceptance is missing.
The user should see a clear explanation:
- which action is blocked: closing, sending for review, moving to control, or changing status;
- what is missing: final file, result link, closed checklist, final comment, assignee, client relation, or another required field;
- who fixes it: assignee, requester, process owner, manager, or LadVen OS administrator;
- how to continue: add the missing item, save the task, and repeat the same action.
Do not close the task through a duplicate, private agreement, or workaround status. If the check requires a final file, attach the file or link. If it requires a closed checklist, close the required items or explain the exception in a comment. If the condition is wrong for this process, ask the process owner to change the check instead of manually breaking a single task.
After the correction, repeat the same action and verify that the task moved to the needed status. If the block repeats, compare the message with the task card: the wrong item may have been fixed, the file may be attached in the wrong place, the comment may not be saved, or the user may not have rights to the required field.
Return to work or rework
Return a task to work when the result does not match the definition of done, files are missing, questions are open, or review found an error. The return must explain exactly what needs to be corrected.
Bad return:
Not acceptable, redo it.
Good return:
Returned for rework: the final table does not have the “Payment date” column, and the description lists it as required. Add the column, fill in rows for clients from the list, and send it for review again.
If the task was already in review or control, after return it usually becomes active again. If the work is no longer needed, cancel the task. If the work is temporarily stopped for an external reason, defer it. If the result cannot be achieved and this must be recorded as a failure, use the unsuccessful completion state.
Manager control when closing
A manager or process owner looks not only at the final status, but also at the quality of the management trail. A closed task should explain why the work was accepted and which decisions were made about deadlines, risks, and new requirements.
Pay special attention to tasks where:
- the deadline was moved or the task is closing after the due date;
- the assignee spent much more time than planned;
- the result affects a client, money, legal documents, a process launch, or another department;
- new requests appeared in comments, but there is no separate related task;
- the task was returned for rework several times;
- part of the checklist was removed or marked irrelevant;
- the task is closed by someone other than the requester.
In these cases, the closing comment should answer the manager’s questions: what was accepted, what changed compared with the original request, why the deviation is acceptable, and where new obligations will be handled.
Closing without losing new obligations
Additional requests often appear during acceptance: “also add the report,” “check the second branch,” “update the template later,” “pass this to another department.” If the original task is closed without recording these requests, they remain in correspondence and do not enter work.
Use a simple rule:
| What appeared during acceptance | What to do |
|---|---|
| A correction to the original result | Return the current task for rework with a concrete list of corrections. |
| A new independent result | Create a related or child task. |
| A future idea without an obligation | Record it in a comment as an idea or a decision not to do it now. |
| An external dependency | Defer the task or create a separate task to obtain the input data. |
| A changed agreement with the client or manager | Record the decision in a comment and link the new task to the original one. |
A closed task should remain a clean acceptance point. Do not continue new work in it if the original result has already been accepted: it becomes harder to control deadlines, owners, and plan versus actuals.
Connection with the definition of done
The definition of done is the main guide for acceptance. It should be in the task description, checklist, or comment if it appeared during the work. Without it, review turns into a dispute about expectations.
A convenient review scheme:
| Where to look | What to check |
|---|---|
| Description | What result was promised and which limitations were specified. |
| Checklist | Whether all required steps are completed and whether unfinished items remain. |
| Files and links | Whether the final version is attached and available to participants. |
| Comments | Whether decisions, clarifications, approvals, and reasons for deviations are recorded. |
| Time | Whether the timer is stopped and actual time is logged if needed for accounting. |
| Relations | Whether there is a parent, child, or related task if part of the result was moved separately. |
If a criterion became outdated, do not ignore it when closing. Record in a comment why it is no longer needed, and only then accept the result.
How to do it in LadVen OS
- Open the task.
- Check the description, definition of done, and expected result.
- Review the latest comments, decisions, and questions.
- Open attached files, links, documents, and related entities if they are needed for review.
- Make sure required checklist items are completed.
- Check the deadline: the task closes on time, with an agreed move, or with a clear explanation of the delay.
- Check the timer and time tracking: the active timer must be stopped before final closing.
- Compare plan versus actuals if the task is used for reporting or workload control.
- If you are the assignee and the result is ready, finish the work or send the task for review.
- If a separate control stage is needed, send the task for control.
- If you are accepting the work and the result matches the criteria, complete the task.
- If corrections are needed, leave a comment with specific notes and return the task to work.
- If a new independent request appeared, create a related task before final closing or immediately after it.
- If the work is no longer needed, cancel the task; if it must be postponed, choose the deferred state; if the result was not achieved and this must be recorded, record unsuccessful completion.
What to check
- the result matches the original agreement;
- the definition of done is met or its change is explained in a comment;
- the deadline was met or the reason for deviation is recorded;
- all required files are attached;
- important decisions are recorded in comments;
- the checklist has no unfinished required items;
- the timer is stopped and time is tracked where required;
- plan versus actuals are understandable for the manager if the task matters for a report or budget;
- related tasks, documents, or CRM entities are added if context would otherwise be lost;
- new obligations are moved into separate related tasks or explicitly rejected;
- participants have no open questions;
- closing does not hide an unfinished stage of the process.
Closing comments
A closing comment is not always required, but it is useful when the task matters for history, a client, a report, or handoff to another person. Keep it short and specific: what was accepted, where the final version is stored, and what was decided not to do.
Examples:
Accepted. The final contract version is attached to the task, and corrections from comments are included.
Closing as canceled: the client moved the launch, and the current preparation is no longer needed. We will return to the task after the new date.
Recording unsuccessful completion: access to the source was not received, and the export cannot be prepared without it. A separate task has been created to obtain access.
When a new related task is needed
Do not turn rework into an endless task. If a new independent result appears, it is better to create a child or related task.
Create a related task if:
- new work appears that was not in the original agreement;
- a separate result must be assigned to another responsible person;
- the correction depends on an external decision or another process;
- the current result can be accepted, and the new requirement must be managed separately.
Return the current task to work if the correction belongs to the same definition of done and the result cannot be accepted without it.
Good practices
- Accept the result by the definition of done, not by “looks done.”
- Return a task to rework only with a concrete list of corrections and the expected result.
- Check the deadline and plan versus actuals before closing tasks that affect a client, budget, or department workload.
- Record management decisions in comments: deadline move, removed checklist item, accepted partial result.
- Create a related task for new independent scope so it does not disappear after closing.
- Do not close a task with an active timer or unsaved time.
- Use manager control for important tasks where acceptance must be separated from execution.
- After several returns, check the original request: the definition of done may have been incomplete or the scope may have changed.
Common mistakes
- closing a task without checking the result;
- finishing work without a final file, link, or summary comment;
- completing a task when it should go through review or control;
- returning a task to rework without a concrete list of corrections;
- asking for corrections in a private message instead of a comment;
- accepting a delayed result without explaining the reason and decision;
- closing a task with a major plan versus actual deviation without a comment;
- treating a new request as a “small correction” when it is a separate result with another deadline or owner;
- leaving an active timer after closing;
- canceling a task instead of deferring it when the work may return later;
- creating a new task for a correction when returning the current task to work is enough;
- continuing the current task when a new independent result appeared;
- closing a task after verbal approval without leaving the decision in the card history.
Needed screenshots
For public documentation, it is useful to prepare these screenshots:
- task card before acceptance: description, checklist, files, and latest comments;
- “In review” status or a similar screen for handing the result to the requester;
- example assignee comment when sending for review: what is ready and where to check it;
- rework return screen with a concrete reviewer comment;
- task under manager control with visible result and related materials;
- time block before closing: timer stopped and plan versus actuals visible;
- related or child task created for a new obligation;
- finally closed task with a summary comment and available files.