> ## Documentation Index > Fetch the complete documentation index at: https://docs.denari.com/llms.txt > Use this file to discover all available pages before exploring further. # Task rules > Tasks are done in order, and a task is ready when the work before it is done. **Tasks are done in order, and a task is ready when the work before it is done.** Holds, send-backs, and changes all keep that order intact. ## Task statuses | Status | Meaning | | - | - | | **To do** | Not started. | | **In progress** | Being worked on. Logging time or starting a timer moves a task here on its own. | | **Done** | Finished. | | **Canceled** | Will not be done. | A task can also be **Blocked**. That isn't a status you pick: it means the work before it isn't done yet, or someone put it on hold. A blocked task can't be started or finished. It can still be reset to To do or canceled. ## Tasks that need time Some tasks are **time-tracked**. You must log time to them before you can mark them done. If you try to finish one with no time logged, Flows asks you to log time first (**Log & complete**). If a timer is running on it, you can stop the timer and finish in one click. If a time-tracked task was marked done with no time logged, it shows an **untracked** badge. ## Put a task on hold Use a hold when a task is stuck for a reason outside the project, such as waiting on documents from the client. * Open the status menu and choose **Put on hold…**. A reason is required. * A held task shows **On hold**. Click the badge to see the reason. It moves to your **Waiting** tab and can't be started or finished. * The hold comes off by itself when someone logs time to the task (saving a time entry or stopping a timer), or when the task is marked done or canceled. You can also click **Clear hold**. ## Send work back When a reviewer finds a problem in finished work, they send it back instead of undoing everything. On a done task in the project's task list. The new task is marked **Redo**. The original stays done as a record of what happened. Choose who should do the redo, and add a note. **After the redo** controls later steps that were already finished. You can **redo from a chosen stage** (for example, send a return back to the preparer and have it come straight back to partner review, skipping manager review), or **don't redo any finished steps**. Later steps that never started just wait for the redo, as usual. ## Change tasks on one project On a project's **Tasks** tab you can: * **Add a task** with **Add task**. Pick its group, what it comes after, who owns it (leave it empty to follow its group), its due date, and its tags. Turn on **Requires logged time** if it needs time to be finished. Turn on **Repeat every period** to also add it to the service's task list, so future projects get it too. * **Add a sub-task** under a task. The task becomes a small group that holds the sub-task. This only works on a task that isn't done and has no time logged. * **Edit, assign, or delete** a task. Click **Assign** on a group to give someone every open task in it. * **Flip the view** between **Top-down** and **Bottom-up** to read the order whichever way is easier. ### This period or future periods too? When you change a task that came from the service's task list, Flows asks how far the change should go. | Change | Choices | | - | - | | **Assigning someone** | **This period** or **+ future**. "+ future" makes that person the owner for this service from now on, including future projects that haven't started. On a group, **This period** adds the person to the group and its open tasks, and **+ future** makes them the group's only owner from now on. Tasks with their own choice keep their owners. | | **Changing a due date** | **This period only** or **This and future periods**. | | **Deleting a task** | **This period only** or **This and future periods**. | Tasks you added by hand to one project only ever change that project. Chained due dates never offer the future choice. ## How tasks get their owners When a project is made, each task gets its owner from the **Assign to** setting on the service's task list: * **Same as group** (the default): it goes to whoever its group goes to. If no group above it has a choice, it goes to Available work. * **Unassigned:** it goes to Available work. * **Partner or Manager:** it goes to whoever sits in that seat on the entity. The task shows a **Partner** or **Manager** badge so you can see why it went to them. See [Relationship roles](/flows/clients-and-entities#relationship-roles-who-plays-which-part). * **Specific person:** it goes to that person. * If the seat is empty, or the person can no longer be assigned, it goes to Available work. Giving a task to someone else keeps its status, its logged time, and its notes. The hand-off is recorded in the task's **Owner history**. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.