# Action Required

Source: https://docs.tai.ga/deliver/action-required/

Action Required is where work returns to you.

When an agent finishes something that needs a decision, or hits something only a person can do,
it lands here rather than waiting silently on a page nobody has open.

It spans every loop and every product you can open:
owners and admins see every product's items, and members and viewers those of the products they belong to.
Reviewing a document, reviewing a plan, reading a pull request
and granting a cloud permission all arrive in the same place,
which is why it is worth checking before anything else.

You do not have to keep it open to hear about it.
A [notification contact](https://docs.tai.ga/administration/notification-contacts/) sends each item to a shared mailbox or a Slack channel,
for one product, a whole factory, or the whole organization.

## It belongs to the team, not to you

The inbox is shared. Anyone with access can pick an item up, and resolving one clears it for everybody.

This is deliberate. An agent waiting on "someone" should not be blocked because the one person
who happened to trigger it is on holiday.

Items you act on are recorded as done or dismissed, and the resolved view keeps that history.

## Two kinds of item

**Things to review.** A plan, a set of initiatives, a document, a pull request, maintenance findings,
or new [policy violations](https://docs.tai.ga/operate/maintaining/#the-document-assessment).
Each is a decision an agent has deliberately handed back rather than made for you.

Findings and policy violations arrive as one item per product rather than one per finding,
because a sweep that turns up nine things is one thing to look at.
The policy item is raised only when a re-assessment after a push to your [integration branch](https://docs.tai.ga/administration/integrations-and-environments/#the-branch-taiga-works-on) records something new,
never for what an import already found, and it clears itself when nothing is left open.

**Things to set up.** Work an agent cannot do because it needs credentials, an account, or access
that only a person holds: an environment variable, a secret, a third-party service,
a [package registry](https://docs.tai.ga/administration/integrations-and-environments/#when-a-registry-is-missing) to connect,
a DNS record, billing approval, or a cloud permission.

Setup tasks raised during planning carry a plain statement of why they are human-only.
If you are wondering why the agent did not just do it, that field is the answer.

## Setup tasks are ordered by when they block you

They are grouped into three phases rather than listed flat, because doing them in arrival order
means doing optional work before the thing stopping your build.

| Phase                   | What is in it                                                                                                                |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| **Before the deploy**   | Credentials, accounts and infrastructure the software needs: environment variables, secrets, API keys, third-party accounts. |
| **Wire run outputs**    | Connecting generated values back to providers: paste, configure, register.                                                   |
| **Optional follow-ups** | Billing approvals, extra cloud permissions and manual configuration that can wait until after launch.                        |

Within a phase, tasks appear in the order agents raised them.

A build does not wait for any of these, and most are in fact created by one:
an agent that hits a missing credential builds around it and flags the task here,
so the work keeps moving.
The first phase's deadline is what its name says: the deploy fails without them.
A missing package registry is filed there too, because a run cannot install your dependencies until you connect it.
Doing them before the run finishes is what makes its result immediately usable.

A setup task names exactly what to set and where.
A task for an environment variable, secret or API key carries the name to set, and you can copy it;
a task whose provider has a console or documentation page links straight to it.
Secret values are never stored or displayed: the task tells you which secret to create,
not what it contains.

## Clearing the inbox

Three ways to make an item go away, and they mean different things.

- **Mark it done.** You did it.
- **Dismiss.** It does not apply and is not going to.
- **Snooze.** Not now. An hour, until tomorrow, or a week.

Nothing marks a setup task done for you.
Connecting the registry or setting the variable is the work, and marking the task done is still yours.

Snooze is the one people skip and then regret.
An inbox where every item is either urgent or permanently ignored stops being read at all.

You can select several items and resolve them together, search, filter to one product, or narrow to one kind of item: plan reviews, run work, or setup.
Maintenance findings and policy violations count as run work.
Keyboard shortcuts move through the list without reaching for the mouse.

## Who can act

Resolving an item, including completing a setup task, needs the same permission as doing the work:
members, admins and owners can. Viewers see the queue but cannot clear it.

That matches the rest of the product, and it is worth knowing before you ask someone
with read-only access to unblock a run.