Review and approve actions

Use this when

Use this guide when you are starting a work session and need to choose what deserves attention first.

An approval is your decision on a proposed action. Before approving, check the target, the content, and the effect. Approving an email proposal can send the message; it is not simply marking the draft as read.

What an approval actually is

AI tools and connected integrations that propose a change stage it here rather than running it immediately: an email draft, a suggested pipeline move, a task change, a prepared reminder. A read-only question, like asking the assistant to summarize a deal, never creates an approval, because nothing about it changes a record.

Manual actions follow the controls on their own screen. For example, a reply you write in Conversations uses the composer and its confirmation flow. It does not need a second AI proposal first.

Reviewing one

1. Open Today → Needs your decision or Work → Approvals, and select a pending item.
2. Read the proposed action and the context behind it. For a message, that means the actual recipient and the actual wording, not just the fact that a message exists.
3. Choose the decision that matches what you actually want.

Decision	What happens
Approve	The action runs as shown. Approving an email proposal can put a message in front of a real customer, not just mark a draft as read.
Revise	The proposal goes back to whatever produced it, AI or workflow, so you can change it and review the new version before deciding again.
Reject	The action does not run. Give a reason when the screen offers one; it is what the system learns from.

Approving and the action actually succeeding are two different events. A provider outage can leave an approved send unfinished, so check the result afterward rather than assuming approval was the last step. Receipts and audit covers the exact statuses to look for.

How approval turns into autonomy

Use Activity and the action's result to investigate. If the outcome is unclear, check the existing request before creating another. Receipts explain the statuses to look for.

From there, an action can reach standing_permission, where it runs without asking you first but still logs everything it did so you can audit it after the fact, and eventually autonomous for the narrowest, most consistently correct patterns. The point of the ladder is that your week gets shorter as it climbs: the third time you approve the same routine reply is also the last time you have to.

Six things never climb this ladder, regardless of how much trust everything else has earned: deleting an account, changing a credential, deleting financial history, exporting your customer database, a high-value refund, and a major financial transfer. Those stay behind a human decision permanently. And whatever rung an action type is on, the reversibility of what it actually does is fixed by design, not by trust level: sending an email, activating a campaign, and sending an invoice are permanently non-autonomous actions in this product, meaning they always require your approval no matter how long you have been running the system, because an email you did not mean to send cannot be called back.

When a standing permission changes

A permission belongs to one workspace and either one coworker or the workspace-wide action. Repeating registration updates that same scope. Changing its level, constraints or source clears the previous approval; changing only its label or description keeps the decision. Restoring standing permission requires an explicit human approver. Hard safety floors remain in force, including floors set for the whole workspace.

Try the review workflow in the demo first. Its data and effects are fictional.

What to know

Availability depends on enabled modules, workspace permissions, provider connections, and the current installation. Check the recorded status before relying on a live result.

Next: Review Today to see how this work fits into the daily operating flow.