> ## Documentation Index
> Fetch the complete documentation index at: https://docs.salesfinity.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Approvals and permissions

> The action policy: what each action class covers, the defaults, what can never run on its own, per-tool overrides, and how an approval works end to end.

Every tool Ari can use belongs to one **action class**. The team's action policy, under
**Settings › Ari › What Ari may do on its own**, sets a decision per class. Because the policy is
written over classes and not over individual tools, a new integration is governed the moment it is
connected.

## Decisions

| Decision    | Meaning                                                                    |
| ----------- | -------------------------------------------------------------------------- |
| **Auto**    | Ari does it without asking and reports it in the work log.                 |
| **Approve** | Ari stops, posts an approval card, and continues only if someone approves. |
| **Block**   | Ari will not do it at all, and says so.                                    |

## Action classes and defaults

| Class           | Covers                                                                               | Default                 |
| --------------- | ------------------------------------------------------------------------------------ | ----------------------- |
| Read            | Reading the CRM, lists, call history, email, calendar, the web                       | Auto                    |
| Draft           | Writing text that is not sent: emails, replies, notes, summaries                     | Auto                    |
| Free enrichment | Filling fields that cost nothing                                                     | Auto                    |
| Paid enrichment | Email and mobile lookups that spend credits                                          | Approve, cannot be Auto |
| CRM write       | Creating or updating contacts, companies, deals, tasks, notes, owners                | Approve                 |
| Send message    | Sending email, posting to Slack on someone's behalf, logging a message that goes out | Approve                 |
| Sequence write  | Enrolling, pausing, finishing or moving people in sequences                          | Approve                 |
| Delete          | Deleting or archiving anything, unsubscribing                                        | Approve, cannot be Auto |
| Skill write     | Saving or updating a skill                                                           | Auto                    |
| Other write     | Any other change to shared state                                                     | Approve                 |

<Warning>
  **Paid enrichment** and **delete** can never be set to Auto. Each already has its own safeguard
  (a per-run credit approval, a confirmation on bulk deletes), and relaxing the class would only hide
  the question. Setting either to Auto is saved as Approve.
</Warning>

## Per-tool overrides

An admin can override the class decision for a single tool, for example allow CRM writes to run on
their own but keep **create deal** on approve, or block **send email** entirely while allowing
other sends. Overrides are listed under the class table with a clear button to remove them. A tool
whose class can never be Auto keeps that rule under any override.

## How an approval works

<Steps>
  <Step title="Ari reaches an action that needs approval">
    The run pauses at that step. Anything before it already happened; nothing after it does.
  </Step>

  <Step title="A card is posted">
    In the Slack thread or DM where the work started, and on the rep's Ari page in the app. The
    card says what will happen, to how many records, and what it costs.
  </Step>

  <Step title="Someone decides">
    The rep who asked, or a team admin. **Approve** resumes the run at that step. **Reject** skips
    that action; Ari continues with what it can and reports what it did not do.
  </Step>

  <Step title="It is logged">
    Who approved or rejected, when, and the action itself land in the work log.
  </Step>
</Steps>

A run with several approvals asks for each one in turn. A run that waits too long for an approval
is not lost: the approval stays pending in the feed until it is decided.

## Questions

Separately from approvals, Ari can ask a **question** when it cannot proceed without a choice only
you can make ("Two CRM contacts match this email; which one?"). Questions appear as cards the same
way and are answered by replying in the thread or on the Ari page.

## Who can change the policy

Team admins. Reps see the policy but cannot edit it. Every change records who made it and when.

## Responsibilities and write mode

A responsibility carries its own write mode on top of the team policy:

| Mode                 | Effect                                                                                                               |
| -------------------- | -------------------------------------------------------------------------------------------------------------------- |
| **Read only**        | Every write is stripped before the run; the responsibility can only report.                                          |
| **Require approval** | The team policy applies as usual; writes that need approval queue a card.                                            |
| **Auto-approve**     | Writes the team policy allows run inline. Writes the policy sets to approve still ask. Never-auto classes still ask. |

The mode can only relax within the team policy; it cannot grant what the policy blocks.