> For the complete documentation index, see [llms.txt](https://docs.imerit.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.imerit.net/core-concepts/tasks.md).

# Tasks

Overview of labeling tasks in Ango Hub

Every labeling project is broken down into [assets](/core-concepts/assets.md), then individual tasks.

### Creating Tasks <a href="#creating-and-deleting-tasks" id="creating-and-deleting-tasks"></a>

Tasks are created automatically when assets are added.

Ango Hub creates one labeling task for each asset.

{% hint style="warning" %}
When an asset is deleted, the tasks assigned to the asset are deleted as well. Importing the asset again will not restore the tasks that have been deleted this way.
{% endhint %}

Tasks are shown in the *Tasks* tab.

<figure><img src="https://3895963154-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FTcOUG6rfWxqGM0N4db2P%2Fuploads%2FuLe4byiQSNJlAKUI5HIo%2Fimage.png?alt=media&amp;token=dbfee8cf-2023-4002-a735-e2832ed7efda" alt=""><figcaption></figcaption></figure>

**Task ID**. Unique identifier associated with each task.

**External ID**. Non-unique identifier for each asset. If importing assets with [drag and drop](/data/importing-assets.md#browser-import), this ID will be equal to the filename of each asset. If uploading using [a JSON](/data/importing-assets.md#cloud-import) or [the SDK](/sdk/sdk-documentation.md), you will determine this ID on import.

**Stage**. Stage where the task is currently located and waiting.

**Assignee**. User currently assigned to annotate the task.

**Updated At**. Time and date when the task was last updated (e.g. submitted.)

**Duration**. Total duration of the task. See the [page on idle detection for more details](/core-concepts/idle-time-detection-and-time-tracking.md).

**Consensus**. The task's overall consensus score. When a workflow contains multiple Consensus stages, the column also shows a completed/total count for each stage. Hover over the value to see the stage names and the users who completed each one.

<figure><img src="https://3895963154-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FTcOUG6rfWxqGM0N4db2P%2Fuploads%2Fgit-blob-e7838ad715c729dc97ab5d309c9928dfa11fb736%2Fconsensus-summary-multiple-stages.png?alt=media" alt="Consensus column showing completion counts for three stages, with a tooltip listing each stage and its users"><figcaption><p>Consensus progress across multiple stages</p></figcaption></figure>

**Last review**. Result of the last review the task went through.

**Open Issues**. Number of open issues on the task.

Other column types are also available. To show/hide them, click on the *Columns* dropdown:

<figure><img src="https://3895963154-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FTcOUG6rfWxqGM0N4db2P%2Fuploads%2Fm5GX4l2Mv3gWxaovmI1i%2Fimage.png?alt=media&amp;token=bdb8f692-09b5-4306-804d-bf49a5e5d4dc" alt="" width="306"><figcaption></figcaption></figure>

### Filtering by annotation answers

Use the *Answer* filter in the *Tasks* tab to find tasks containing or missing a tool, classification, or classification option. *Exists* and *Does not Exist* also work for nested classifications, including classifications under a Text classification and those displayed for any parent option. All selected conditions must match.

For a top-level Text classification, you can search for text instead. Typing a search replaces its existence selections and hides the nested choices while the text search is active.

The same answer conditions are available in the [Logic stage](/core-concepts/workflow/logic.md#annotation-type) to route tasks through a workflow. See that page for the limitations on video and multi-frame DICOM tasks.

### Bulk accepting or rejecting review tasks

Project Leads and Managers can bulk accept or reject tasks from the *Tasks* tab when the task list is filtered to a single *Review* stage.

To do so:

1. Open the *Tasks* tab of your project.
2. Filter the table to one *Review* stage from the stage filter.
3. Add any other filters you need, such as batch or assignee.
4. Select the tasks you want to accept or reject.
5. Open the selected-items dropdown and choose *Bulk Accept* or *Bulk Reject*.

If you use *Select all items in the list*, the bulk action applies to every task matching the current filters, not only the tasks currently visible on the page.

*Bulk Accept* and *Bulk Reject* only appear when the table is filtered to exactly one *Review* stage. They are hidden when no stage is selected, when multiple stages are selected, or when the selected stage is not a *Review* stage.

### Deleting Tasks <a href="#creating-and-deleting-tasks-manually" id="creating-and-deleting-tasks-manually"></a>

To delete a labeling task, select the task(s) you wish to delete with the checkboxes on the left, then click on *Actions* and click on *Delete*.

<figure><img src="https://3895963154-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FTcOUG6rfWxqGM0N4db2P%2Fuploads%2FAfFiR4pbglDr8lJSaLkU%2Fimage.png?alt=media&amp;token=abb21380-ffa2-4786-b862-bb8a396e41e4" alt="" width="563"><figcaption></figcaption></figure>

{% hint style="warning" %}
Deleting tasks is a destructive and irreversible action.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.imerit.net/core-concepts/tasks.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
