# Action approval: what your tools do without you

<Lead>
Software that acts on its own raises exactly one question: **what does it do without me?** Action approval is the answer, and it lives in one place instead of being scattered across ten tools.
</Lead>

## The principle: a level per impact, not per tool

A tool does very different things. DB-Leads, for example, searches and scores your database, writes an assessment into your CRM, and can email a contact. With a single switch you would have to choose: either block the harmless scoring to prevent the email, or accept the email to get the scoring.

That is why there are three **impact classes**. The classification follows what happens in the worst case, not which technology is behind it: whether a message goes out by email or WhatsApp changes nothing for you. Whether it goes out at all changes everything.

<DefinitionList>
  <DefItem term="Inside the workspace only">
    Scoring, assessing, creating tasks, producing reports. Never leaves your workspace and can always be undone.
  </DefItem>
  <DefItem term="Writing to the CRM">
    Fields, activities and tasks in the connected CRM. Colleagues see it, and the interface cannot take an activity-log entry back out.
  </DefItem>
  <DefItem term="Message to a contact">
    An email, a WhatsApp message or a link to someone outside your office. Not recallable once it is out.
  </DefItem>
</DefinitionList>

## The three levels

For each class you pick one of three levels.

<DefinitionList>
  <DefItem term="Automatic">
    Runs without asking. You learn about it in the run report.
  </DefItem>
  <DefItem term="Approval">
    The tool prepares the action and waits. You see the finished text beforehand and decide.
  </DefItem>
  <DefItem term="Off">
    Does not happen. The run records it as skipped, with a reason.
  </DefItem>
</DefinitionList>

<Info>
**Off is not the same as approval where you never approve.** A queue that fills up and is never emptied is a source of errors. If you do not want something at all, set it to off.
</Info>

## What you start with

Out of the box:

| Impact class | Default |
|---|---|
| Inside the workspace only | Automatic |
| Writing to the CRM | Approval |
| Message to a contact | Approval |

So scoring runs from day one, because a tool that may not even compute without asking is not a tool. Anything that leaves the office or touches other people's records waits for you.

That is a deliberate decision, not caution: an automation you switch on after seeing what it does is your decision. An automation that runs from the start is a surprise, and the first unexpected email to a client is usually the last time anyone trusts the software.

## What the gate does not cover

**Whatever you click happens immediately.** When you press "Write to CRM" or "Send request", you have already decided with that click; asking again afterwards would be the same question twice.

The levels apply to what happens **without a click**: an overnight run, an automation after a scan, a scheduled follow-up message.

## Setting a level

<Steps>
  <Step title="Open the tool">
    Go to **Settings · Automation** and click the tool in question. Every tool has its own page there.
  </Step>
  <Step title="Pick the level">
    The three classes are listed one below the other. Under each, the actions that fall under it are spelled out. Pick the level.
  </Step>
  <Step title="That is all">
    The change applies to the next run. Approvals already waiting stay in place and can still be decided individually.
  </Step>
</Steps>

Switching a class that writes to the CRM or reaches outside to **automatic** asks you once more. That is the only change on this form with real consequences that need no further action from you. Every other change makes the system more cautious and needs no brake.

The same page also shows what this tool has currently prepared for approval, and what became of earlier approvals. At the bottom, **Stop this tool entirely** sets all three classes to off in one click.

<Info>
The levels deliberately do **not** live with the tool's other settings. They belong to the platform, not to the tool: they are checked against the tool when it sends, and a tool should not manage its own gate. The tool settings therefore only carry a pointer with the current state.
</Info>

## Deciding approvals

When a class is set to **approval**, prepared actions collect under **Approvals**. A counter appears in the top bar as soon as something is waiting.

Each row shows:

<Checklist>
  <ChecklistItem>which tool prepared the action, and in which class</ChecklistItem>
  <ChecklistItem>who it would go to, with the address partly masked</ChecklistItem>
  <ChecklistItem>the **finished text**, exactly as it would go out, not a description of it</ChecklistItem>
  <ChecklistItem>when it was prepared and when it expires</ChecklistItem>
</Checklist>

You decide with **Approve** or **Reject**. Both remain on record; a rejected approval does not vanish without trace.

<Info>
**Approvals expire**, by default after seven days. The reason: a message that waits three weeks and then goes out refers to an occasion both sides have forgotten. That is worse than not sending it at all. Once expired, it can no longer be approved.
</Info>

## The overview

Under **Settings · Automation** all your tools appear with all three classes on one page. Anything that writes to the CRM or goes outside without asking is highlighted and sorted to the top.

That is the page for the question this text opened with. It answers it at a glance, instead of making you open ten tool pages one after another. On top of that:

<Checklist>
  <ChecklistItem>A filter narrows the list to tools that act **on their own**, or to those with something **waiting for you**</ChecklistItem>
  <ChecklistItem>The **history** lists what became of recent approvals: executed, rejected, expired or failed</ChecklistItem>
  <ChecklistItem>**Stop everything** sets every class in every tool to off, in one click</ChecklistItem>
</Checklist>

<Warning>
**Stop everything** is meant for the moment when something goes out that you did not want and you do not yet know which tool did it. Tools you are not allowed to configure are **not** switched off, and the message names them. An emergency stop that silently skips half of them would be more dangerous than none.
</Warning>

<Info>
The history shows **approvals**, not every automatic action. Anything set to "automatic" runs without an approval and therefore does not appear there. The more that runs automatically, the emptier this list gets. The full record lives under **Operations · Activity**.
</Info>

## How this relates to advertising opt-outs

Not at all, and that matters. These are two separate checks, and both apply:

- **Action approval** answers: may this tool do such a thing on its own?
- The [advertising opt-out](/help/compliance/werbewiderspruch) answers: may **this particular person** be contacted?

Even at level "automatic", no advertising goes to someone who has objected. Conversely, a missing objection does not help if you set the class to off.

<Faq>
  <FaqItem question="I switched on an automation and nothing happens.">
    First check whether the tool declares anything in that class at all: if the row says "not declared", the level has nothing to decide there. Then check the advertising opt-out: contacts without consent receive no advertising, regardless of the level.
  </FaqItem>
  <FaqItem question="Who may change the levels?">
    Whoever may configure the tool. That is the same permission as for its other settings, because whoever sets up a tool also decides what it does on its own.
  </FaqItem>
  <FaqItem question="Can I see what an automation did?">
    Yes. Every run reports what went through, what is waiting for approval, and what was skipped. Held-back items are counted separately from failures: "waiting for approval" is a different statement from "failed". The full record lives under **Operations · Activity**; the history on the automation page only covers decided approvals.
  </FaqItem>
  <FaqItem question="Can a tool do something that does not appear in the settings?">
    No. An action a tool has not declared does not run on its own. The direction is deliberate: a message the settings page knows nothing about would be one you could not switch off, because the switch for it would not exist.
  </FaqItem>
</Faq>