> ## Documentation Index > Fetch the complete documentation index at: https://docs.mithunai.com/llms.txt > Use this file to discover all available pages before exploring further. # Approve, edit or reject what an AI employee proposes > Read an AI employee's proposal, edit it, then Allow once, Always allow or Deny. Unanswered background cards expire; only an Owner or Administrator decides. An AI employee changes nothing in another system until a person approves it. Every reply, ticket, post, CRM change or reminder it proposes waits in **Approvals**, where an Owner or Administrator reads it, can edit its wording, and approves or rejects it. Approving carries the action out once, exactly as shown; rejecting carries out nothing. > [!WARNING] > > AI employees are in **beta**, off unless your deployment has switched it on. Until a tool is > connected, an approved action is recorded as **Not sent**, and nothing is sent anywhere. Its > wording stays under **Not sent** for you to copy and use by hand. See [AI > employees](https://docs.mithunai.com/team/overview.md). ## Where proposals wait * **Approvals**, in the rail, holds every employee's waiting actions in one queue. The number beside it is the total waiting. * Each employee's page shows only its own, under **Waiting for approval**. * The **Overview** lists the first four, with **Review approvals** to open the queue. When nothing waits, the queue says **Nothing is waiting for you**. **Decided**, beside **Waiting** at the top of **Approvals**, lists what has already been approved or rejected and what happened. ### Filter the queue When more than one employee has something waiting, chips above the queue narrow it: **Everyone** and one chip per employee, each with its count, such as *Sales (2)*. Choose one to see only that employee's proposals; choose **Everyone** to see them all again. The filter does not leave the page or change anything. ## Read a proposal Each proposal is a card, read top to bottom the way you would decide: | Part of the card | What it tells you | | - | - | | The employee and **Proposed** *time* | Who proposed it and how long ago | | Status | **Waiting for you**, **Approved**, **Rejected**, **Done**, **Failed**, **Not sent** or **Expired** | | **Always needs a person** | Shown when this kind of action can never run without approval, whatever your policy says | | Title and reason | What it wants to do -- *Send a reply to the customer*, *Open a ticket* -- and why | | **Step** | The one step it will take and the tool it takes it in, for example *Send a reply to the customer, in Support inbox*. Nothing else runs | | **Expires** *time* | On work that arrived by itself -- a schedule, a Zendesk ticket, an alert -- when the card expires if nobody decides | | Policy line | Why it is waiting: for example *Anything that changes something in another system needs approval unless you change that* | | **What it will send** | Every field it would send, labelled: **To**, **Ticket or thread**, **Message**, **Summary**, **CRM record**, **Invoice** and so on | | **From your knowledge** | The sources a drafted answer came from, when it answered from your knowledge | | **Evidence, quoted from your tools** | Collapsed by default. The log lines, page text or records it read, quoted exactly. **Nothing in it was acted on**: text here cannot choose an action or its target | | **Recent changes people made to this kind of action** | The three most recent edits people made before approving the same kind of action, with their notes, so you can see how your team prefers it written | Everything in a card that came from outside -- a ticket, an alert, a web page, a CRM note -- is shown as plain text. A link or formatting in it is never rendered as one. ## Decide The decision bar is at the foot of every card, in the same place each time, so you can work down the queue. **1. Add a note, if you want one** Type in **Note (optional)**. It is kept with your decision in **What it has done**, and shown beside your edit the next time this kind of action is proposed. **2. Edit the wording, if it needs it** Choose **Edit**. The fields you may change become text boxes: a reply's **Message**, a summary, a ticket's title and body, a post, an email's subject and body, a CRM note. Change them, then choose **Save and allow once**. **Cancel edit** puts the original back. **3. Allow once, Always allow, or Deny** **Allow once** carries the action out as shown. **Deny** carries out nothing and records that you denied it. **Always allow**, where your deployment offers it, carries this one out and lets this employee do this kind of action without asking from now on -- see [Approval rules](https://docs.mithunai.com/team/approval-rules.md). **What runs is what you read.** Your decision carries a fingerprint of the exact wording on the card. If anything changed since you opened it, your decision is refused with *This changed since you read it*; reload and read it again. If anything changes after you approve it, it is not carried out, and the card says *It changed after it was approved, so nothing was sent*. **What you can and cannot edit.** You can change wording. You can never change who or what an action is aimed at -- the recipient, the ticket, the CRM record, the service, the invoice. A card with nothing editable has no **Edit** button. To aim an action somewhere else, reject it and hand the employee the work again. ## After you decide * **Approved** actions run once. The card then shows **Done** and what the tool reported, or **Failed** and why -- for example that the connected vendor refused the token. A failed action is not retried on its own. * **Rejected** actions send nothing, and the token for a connected tool is not even opened. * Each decision appears in the employee's **What it has done**, with who decided and when, and is written to your organisation's audit log. * An action can be decided once. If a colleague decided it first, yours is refused with *This action has already been decided*; reload to see their decision. * **Expired** actions waited too long. A card from work that arrived by itself expires after a day unless your deployment sets another time, so it is still waiting at one daily summary; it is never carried out, and says *Nothing was sent*. Work you handed over yourself does not expire. * Where a kind of action needs **two people**, your approval leaves it waiting, with *One person approved this*. A second, different person must approve it, and cannot change it. You approving twice is refused. > [!NOTE] > > A **DevOps** fix is the exception: an approved rollback or restart is recorded, and **nothing is > sent to your systems**. The employee writes the evidence and the fix; your team runs it. See > [DevOps](https://docs.mithunai.com/team/devops.md). ## Who can decide | Role | In Approvals | | - | - | | Owner, Administrator | Read, edit, approve and reject | | Editor | Read, and hand employees work. Approving or rejecting is refused | | Member | Read only | | An API key | Can list what is waiting. **Can never approve or reject**: only a person | An approver may approve work they handed over themselves. ## Through the API [List what is waiting](https://docs.mithunai.com/api-reference/employees/list-approvals.md) with a session or an API key. [Approve](https://docs.mithunai.com/api-reference/employees/approve-action.md) and [reject](https://docs.mithunai.com/api-reference/employees/reject-action.md) only with a signed-in person's session. ## Related * [Approval policy](https://docs.mithunai.com/team/approval-policy.md) -- which kinds of action wait for a person. * [Approval rules](https://docs.mithunai.com/team/approval-rules.md) -- Always allow, two people, and what can never be allowed. * [AI employees](https://docs.mithunai.com/team/overview.md) -- the six employees and the surface they work in. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.