Review and approve actions

When AI prepares a customer reply or a workflow proposes several tasks, review the exact change before it runs. Approvals keeps that decision connected to its context and recorded result. Eligible actions can earn a proposed increase in autonomy, which a person reviews separately.

What an approval 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.

A manual action you take yourself is different and does not route through this queue at all. Writing and sending a reply in Conversations uses that screen's own composer and confirmation step; it does not need a second AI proposal stacked on top of something you already decided to do.

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 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.
Save draft to Gmail	For a create_gmail_draft proposal, saves the exact reviewed reply as an editable Gmail draft. It is not sent; review, edit, and send it in Gmail Drafts.
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.

Gmail follow-ups stay in Work → Follow-ups after the draft is saved. Open the draft there, then send it manually from Gmail when it is ready. Gmail sync records the sent message and keeps the follow-up open while waiting for a reply. A matching reply closes that loop; the reply itself remains available in Conversations for any new work. If sync is stale or the provider result is uncertain, the item remains open for reconciliation rather than being silently closed or retried.

Draft access is optional in Setup → Gmail draft access. Google’s gmail.compose scope technically permits sending too, but this follow-up action calls Gmail’s draft-creation method only. It never calls a send method. See Google’s draft creation reference and OAuth scope list for the provider-level distinction.

Approving and the action 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.

Why an action reached you

Autonomous work proposes changes on a schedule whether or not you are waiting, so something has to decide which proposals are worth your attention. That check runs before the proposal is written, and every item in the queue carries the reason it earned a place.

Each proposal is scored for how much a decision would change the business, how well the evidence supports it, how much of your attention it costs, and whether it is worth checking before anyone is interrupted. From those scores it takes one of three routes:

Route	What happens
Surface it	The proposal is queued for review with the reason attached, so you can see why it reached you.
Check first	The finding is too thin to act on but too promising to drop. It stays with the work that raised it, and no approval is created.
Hold it back	The proposal is not written to the queue. A recorded receipt keeps the scores and the reason, so the decision stays auditable rather than disappearing.

Two things are never held back. Anything you asked for directly is always surfaced, however small, and so is anything that would pass a threshold your workspace has set. A workspace with no threshold configured keeps the previous behavior and loses nothing.

If the check itself cannot run, the proposal is queued anyway. A broken heuristic is never allowed to quietly discard real work.

When nothing is reported

Background checks that find nothing actionable finish quietly instead of reporting that they found nothing. A daily sweep that sees no stale deals records that it looked and concludes there is nothing to do; it does not add a line to your queue. That is a successful check, not a failure, and it is not a sign the automation stopped.

Look for these conclusions in Activity when you want to confirm a check ran. If a check that should have run is missing from Activity entirely, treat that as a real problem rather than a quiet outcome.

An autonomy policy sets how a particular action is allowed to run. New policies default to always_ask, which requires review. An action configured as ask_until_trusted can become eligible for a proposed promotion when its executed approvals meet the current threshold of three approvals over at least seven days, subject to the policy checks.

A person confirms any promotion. Eligible actions may then use standing_permission, which authorizes work within its recorded constraints while preserving an audit history. Repeating an approval never grants a new permission by itself, and changing the permission’s scope or constraints requires renewed review.

Hard safety floors remain in force for account deletion, credential changes, deletion of financial history, customer-database exports, high-value refunds and major financial transfers. The reversibility rules also keep sending an email, activating a campaign and sending an invoice behind a human decision. Check the policy for the specific action instead of assuming that another action’s approval history applies.

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.

If an older installation reports multiple matching policies when saving approval, have the workspace administrator apply the current migration catalog and retry the supported policy operation. The recovery keeps existing policy IDs and creation dates, records the before-and-after decision in the audit, and leaves other workspaces and coworker scopes untouched. Unknown constraints still require review even after a standing permission is saved.

Practice it first

Try the review workflow in the fictional demo before you rely on it for real work. Its data and every action inside it are fictional, so nothing you approve or reject there reaches an actual customer.

Undoing an executed task write

Creating, updating, reopening or deleting a task in the workspace runs through the same executor as any programmatic write, so every save leaves a claim, an authorization entry and an audit receipt. When the action is reversible, the prior state is captured at execution: the created row, the previous field values including the description, or the full deleted row.

An executed reversible action can be undone exactly once, restoring that captured state. A second undo is refused rather than re-applied. Irreversible effects, such as a sent email or an activated campaign, can never be undone; only a human approval runs them in the first place.

What to check

• An external assistant connected through MCP cannot approve its own staged proposal. Its own confirmation prompt is not the same thing as your approval inside Command Center, and the action still waits here regardless of what it told you.
• Do not assume repeated approvals have quietly removed a gate on their own; check the current autonomy setting for that action type if you are unsure whether it still needs your review.
• If an approved action's outcome is unclear, inspect Activity and the action's own result before creating a second attempt. Retrying blind risks a duplicate send.