## Overview

Platform automation has always had more than a hundred triggers — conversation created, label
changed, order paid, contract signed — and **none about the Bot**. You could automate on almost
anything except the event that matters most to anyone running AI-assisted support: **the Bot claiming
an action it never executed**.

There are now **five triggers** about the health of an AI turn. They appear in the same **Automation**
screen you already use, with the same catalog of actions (assign, label, private note, priority,
status, webhook…).

| Trigger (as it appears in the list) | Fires when |
|---|---|
| **Maestro — Reply claimed an action that never ran** | The reply asserted a result the turn **did not** execute — or executed and it **failed**. This is the unsupported-claim trigger. |
| **Maestro — Reply altered by verification** | Verification **changed the reply** before delivery (deleted a sentence, removed a fabricated link/price, softened a passage). |
| **Maestro — Tool call failed** | A module action the Bot invoked (calendar, billing, task, catalog, records…) **failed** during the turn. |
| **Maestro — Turn failed without replying** | The turn **died mid-way** and nothing was delivered to the contact. Nobody answered, and the contact is still waiting. |
| **Maestro — Handoff to a human requested** | The Bot **asked for a person** (contact frustration, out of scope, repeated failure). |

All five are **reaction, not prevention**: they alert and organize work after the fact. To **stop** a
doubtful reply from reaching the contact, the mechanism is a different one — holding the reply, in
the turn-verification article (under "See also").

## Prerequisites

- **Maestro enabled** on the account and a **Bot configured** on the inbox handling the conversation.
- **Administrator** permission to create and edit automation rules.
- The **per-module tools** the Bot uses must be enabled — their execution is what produces the
  "failed" and "claimed without executing" signals.
- An **owner** (agent or team) to receive whatever the rule dispatches. A trigger with no recipient
  is just noise.
- Nothing else to provision: the events come from the Maestro service itself. On an account without
  Maestro the rule simply never fires — it stays inert rather than erroring.

## Step by step

1. In **Settings → Automation**, create a **new rule**.
2. Give it a clear **name** — names like "AI claimed a booking" save minutes of investigation later.
3. For the **trigger**, pick one of the five "Maestro —" events in the list.
4. **There will be no filters to choose.** That is expected and explained in the settings section
   below. The rule applies to **every** occurrence of that event on the account.
5. Pick the **actions**. For these triggers the most useful ones are usually:
   - **Add label** (e.g. `review-ai`) — cheap, silent, and lets you measure volume before turning on
     notifications;
   - **Add private note** mentioning the supervisor — the mention fires the native notification;
   - **Assign to a team** and **change priority**;
   - **Change status** (for example, un-resolve when the turn failed);
   - **Webhook**, if you track this on an external dashboard.
6. Save and leave the rule **active**.
7. After a day of operation, filter the conversation list by the label the rule applies. That is your
   volume thermometer before escalating to notifications.

## Settings & options

### Filters (conditions): not available yet for these five triggers

When you pick one of these triggers, the **conditions area stays empty**. That is a deliberate
decision, not a missing field: the turn-specific information (verdict, which tool failed, severity)
**travels in the event**, but there is still **no server-side matcher** that can compare it. Offering
a filter field that would in practice match everything is worse than offering none — it would look
like it works and it would not.

Practical consequence: **the rule fires on every occurrence**. Size the action accordingly. Start with
a label, measure, and only then add notifications or assignment.

### Available actions

The **full conversation action catalog** works, because the event resolves to the conversation where
the turn happened.

> **Be careful with "send a message" on these triggers.** These are events about an **internal
> failure**. Sending the contact an automated message when the Bot stumbled usually makes things
> worse. Prefer private note, assignment, label and priority.

### What the event does **not** carry

For privacy, the event carries only identifiers and the kind of occurrence. **Reply text, tool
arguments and the prompt never travel.** You cannot (and will not be able to, from here) print the
reply content in an automated note — to read what was said, open the conversation.

### One name, two meanings

There is a **notification** called "Maestro Approval" (approval of a Brain department run) that
internally uses wording similar to the **Handoff to a human requested** trigger. They are different
things in different places: one is a Brain notification, the other is an automation rule trigger. If
you look for one on the other's screen, you will not find it.

## Use cases

- **Supervisor alerted when the Bot claims a booking that never happened** — trigger *Reply claimed
  an action that never ran* → private note mentioning the supervisor + assign to the scheduling team
  + **high** priority + label `review-ai`. This is the classic case: the contact leaves believing
  they have an appointment, and somebody needs to call before they show up at the door.
- **Contact left hanging** — trigger *Turn failed without replying* → assign to a human immediately
  and set the status to open. The urgency here is higher than in the other four: **nobody answered
  at all**.
- **Handoff queue** — trigger *Handoff to a human requested* → assign to the right team and set
  priority, so the Bot's request does not die in an unowned conversation.
- **Broken integration surfacing early** — trigger *Tool call failed* → label `tool-failed`. Three
  days later the label shows which module is failing most often (expired credential, missing
  required data, module rule blocking the operation).
- **Weekly quality review** — trigger *Reply altered by verification* → label only. Expect **this to
  be the noisiest of the five**: every cosmetic correction counts. Use it as a Friday reading sample,
  not as an alert.

## Tips, limits & best practices

- **These triggers prevent nothing.** They react afterwards. When you need the reply **not to go
  out**, the path is holding for verification or human approval — not an automation rule.
- **Start with a single rule.** Five rules with notifications, all switched on the same day, produce
  five times more noise than the team can read — and the natural reaction is to turn everything off.
- **Label first, notify later.** It is the cheap way to learn your operation's real volume before
  committing someone's attention.
- **No filters means no exceptions**: you cannot restrict the rule to one inbox, one time window or
  one kind of verdict. If you need a slice, it has to happen when reading (via the label), not in the
  rule.
- **Nothing is written to a table of its own** by these events: they route the signal into
  automation. The durable turn record lives in Maestro. In other words: if you create no rule, the
  event passes and leaves no trace in the automation area.
- **Failures are isolated per rule**: if one rule's action breaks, the other rules on the same event
  keep running.
- **Combine with human approval** on sensitive actions (money, cancellation, records). The rule is
  the safety net below; approval prevents the fall.

## Troubleshooting

- **"I created the rule and it never fires"**: check, in this order — the rule is **active**; the
  inbox has a **Bot** answering; **Maestro is enabled**; and the event actually happened. A turn that
  goes well produces none of the five — silence can be good news.
- **"It fires too much"**: expected behavior while there are no filters, especially on *Reply altered
  by verification*. Switch to a cheap action (label), or turn that specific trigger off and keep the
  other four.
- **"I cannot find the filters/conditions"**: they do not exist yet for these five triggers. It is
  documented above — it is not a problem with your account.
- **"The contact received a strange message"**: one of these rules has a **send message** action.
  Replace it with a private note.
- **"The private note showed up for the customer"**: private notes are not delivered on any channel.
  If the text reached the contact, it went out as a **normal message** — review the rule's action.
- **"I want to know exactly what the AI said"**: the event does not carry the text. Open the
  conversation and read the delivered message and the private notes.

## See also

- [Automation rules: triggers, conditions and actions](/hc/ajuda/articles/automation-flows-regras-de-automacao-en)
- [Turn verification and holding the reply](/hc/ajuda/articles/maestro-brain-verificacao-de-turno-en)
- [Checking what the Bot claims before it is sent](/hc/ajuda/articles/maestro-brain-verificacao-do-que-o-robo-afirma-en)
- [Bot autonomy modes and human approval (HITL)](/hc/ajuda/articles/maestro-brain-autonomia-e-aprovacao-humana-en)
- [Maestro tools by module](/hc/ajuda/articles/maestro-brain-ferramentas-maestro-por-modulo-en)