Approvals
Review the changes agents propose in the Inbox, then approve, edit or reject them.
The Inbox is where Meerkats asks for a decision. When a rule or an agent wants to change something in a connected tool, it doesn’t make the change; it stages a proposal here with the evidence, and waits. You approve it, edit it, or reject it. Nothing changes until you do, unless you have allowed that rule to act on its own.
Open it from Inbox in the sidebar, or from the inbox icon at the top right of Cockpit (Inbox — fixes & recommendations).
What's in the Inbox#
| Section | What lands here |
|---|---|
| Agent runs — need approval | Changes proposed by rules and agents in suggest mode: pause, enable, budget, bid, negative keywords, created campaigns, CRM updates. Each has a risk class and the evidence. |
| Suggestions — need approval | Recommendations from Meerkats's own analysis that no rule asked for, for example a budget reallocation or a tracking fix. Regenerate refreshes them from current data. |
The count next to each section is how many are waiting. All clear — nothing waiting on you means exactly that.
Read a proposal#
Every proposal shows the same things, in the same order, so you can decide quickly.
| Part | What it tells you |
|---|---|
| Title and risk | What will change, and whether it is low, medium or high risk |
| Origin | The rule that fired, the investigation that found it, or the request that asked for it |
| Evidence | The metric, its value over the window, and what changed. Every number carries its source and links to the query behind it |
| Why | The chain from symptom to cause through the relationship graph, for example: conversion fell on hero-SKU terms → rival cut price on the matched listing on Tuesday |
| Before state | The target's current values, fetched in this run: budget, status, bid |
| The change | Exactly what will be set, and the cap if the request was clamped |
| Forecast | The metric it expects to move, by how much, over what window, and the prior that forecast came from. No account prior means wide bands, and says so |
| Reversible | Whether it can be undone, and how |
| Expires | When the approval lapses |
A plan can hold several lines, for example the same rule firing on three campaigns. One approval covers the plan; you are not asked line by line.
Approve, edit or reject#
- Open the proposal
Select it under Agent runs — need approval.
- Decide
- Approve. Meerkats re-reads the target live, applies the change, reads it back, and records the value it replaced. If the target moved since the proposal, it stops and re-proposes instead.
- Edit. Change a number, for example the budget amount. Meerkats re-resolves everything that depends on it, restates the difference, and offers the plan again.
- Reject. Say why if you like. The reason is stored as a known failure mode, so the same proposal doesn’t come back.
- High-risk changes confirm twice
Activating something Meerkats created, moving budget across platforms, or touching a protected entity asks a second time, after the read-back shows no difference from the plan.
- Check the result
Open Automation Agents › Agents run history. The run shows the approval, who gave it, the change, the read-back, and the watch that is now tracking the outcome.
Approve all low-risk#
The button at the top of Agent runs — need approval approves every low-risk line in one go: bid reductions, budget reductions inside the cap, negative keywords. Medium and high-risk lines stay for individual review. The count in brackets is how many it will approve.
What happens after you approve#
- Meerkats re-reads the target’s live state. Any drift from the before state stops the run and re-stages the proposal with what moved.
- It applies the change in the platform, within the caps.
- It reads the object back and compares with the plan. A difference stops the plan and is reported verbatim.
- It records the change with the previous value, so it can be undone from Agents run history.
- It attaches a watch with the forecast as the yardstick. A first read at three days, a verdict at fourteen. If the outcome diverges, an investigation starts and you are told with the diagnosis under way.
Expiry and timing#
- Each proposal expires. The time is shown on it. An expired proposal is re-validated against live data and re-staged; it is never executed as-is.
- The rule’s cooldown starts when it fires, not when you approve. A rule with a 24-hour cooldown won’t re-propose on the same target for a day, whatever you decide.
- Proposals on an object in a platform learning phase are held, and the hold shows its end date.
Who can approve#
Anyone with Read & Write access to the workspace. People with Read Only access see the Inbox and the evidence but cannot approve, edit or reject. Access is set when you share a workspace (Workspaces in your account menu, then the share icon). Every decision is recorded with the person who made it in Agents run history and in the workspace Activity log.
Approvals in Slack
With Slack connected, a rule can post its proposals to a channel with Approve and Reject buttons. The decision is recorded the same way, against the Slack user who pressed the button, and the person must have Read & Write access.Let a rule act on its own#
Once a rule’s proposals have been right for a while, you can switch it to auto for its action type. Only low-risk actions can run alone, caps still apply, protected entities are never touched, and every automatic run writes the same record as an approved one. Meerkats recommends the switch only when the rule’s predicted-versus-actual record clears an accuracy bar. See Autonomy.
Approvals over the API#
Your own tools can read and decide proposals. The key needs read scope to list, write to approve or reject.
GET /automations/staged
→ the staged actions awaiting approval in the key's workspaceA decision made through the API is recorded against the app that holds the key.
Troubleshooting#
I approved, but the change didn't happen
Open the run in Agents run history. Either the target moved between the proposal and the approval, so Meerkats re-proposed, or the platform rejected the change and the run shows its error.
The Approve button is missing
You have Read Only access to this workspace. Ask the workspace owner for Read & Write.
A proposal disappeared
It expired, or someone else decided it. Expired proposals come back re-validated if the condition still holds. The Activity log shows who decided.
The same proposal keeps coming back
Reject it with a reason. The reason is stored and the rule stops proposing it. Or edit the rule's threshold or window.
I want to undo an approved change
Open the run in Agents run history and select the rollback. Meerkats restores the stored previous value and records the reversal.