How For review works

Automations are in open beta, available to customers on the Pro plan.

For review is the human-in-the-loop surface that sits alongside automations. When an automation shouldn’t apply a change on its own, a step produces a draft instead, and a person approves or dismisses it afterward. This page covers how those drafts are produced, who they’re routed to, and what happens when a reviewer acts on one.

Because runs execute to completion without interruption, For review is how a human stays in the loop: the run finishes, produces its drafts, and the review happens after the fact rather than mid-run.

What a review item is

A review item is a draft an automation made for someone to approve, with the context they need to decide:

• the draft itself (for example, an email),
• why the automation produced it,
• the records it’s about (the account, opportunity, or contact),
• a link back to the automation run that created it, so you can always see where a draft came from.

For now, email drafts are the only available review item type. Record creation, record updates, and more are coming to For review.

How items are produced

During a run, a step can either make a change directly or send it to For review instead. When it sends something for review, the draft becomes a pending item assigned to a reviewer, tied back to the run (and the step) that proposed it.

If a later run proposes the same change again, it replaces the earlier pending draft instead of stacking up a duplicate, so a reviewer only ever sees the current proposal.

Who reviews an item

Each review item is routed to one or more reviewers: the people for whom the draft is relevant. The reviewer is chosen from the people connected to the draft: the participants on the related records and activity (for example, the owner of the account, or the sender and recipients on an email thread), and the identity the run executed as.

Two rules shape routing:

• Every item has at least one reviewer. If no relevant person can be found, the draft isn’t created rather than sent to nobody (or everybody).
• Routing respects run privacy. A review item is only ever visible to people who can see the originating run. A run that executed as a specific user produces drafts visible only to that user and workspace admins; a workspace-user run produces drafts visible across the workspace.

For email drafts specifically, only a reviewer whose connected account matches the draft’s “from” address can actually send it. Other reviewers (such as admins) can see it but not send on someone else’s behalf.

Where reviewers find items

A reviewer works through their pending items from the For review page. Opened from the global sidebar, it’s the dedicated queue of everything pending for that reviewer, where items can be worked through, approved, or dismissed.

Two more surfaces are planned to bring pending items to where the work already is:

• Up next: a member’s most recent For review items will appear at the top of Up next, alongside their meetings and tasks, so the day’s pending work is visible without leaving the home surface.
• Related record pages: a banner on the related account, opportunity, or contact will surface the pending items tied to that record, so a reviewer sees proposed changes in the context of the record they’re about.

Acting on an item

Before acting, a reviewer can edit a pending item (for example, adjust the body or recipients of a drafted email) so the draft reflects what they actually want before it’s applied. Edits are saved on the pending item and used when it’s approved.

A reviewer then takes one of two actions:

• Approve: the draft (with any edits) goes through. For an email, approving sends it.
• Dismiss: the draft is discarded and nothing happens.

Only one person needs to act on a draft, and once it’s been approved or dismissed it leaves the queue. If the same email gets sent or discarded another way (directly from the record, say), the draft drops out of For review on its own, so the queue never shows something that no longer needs a decision.

Working with the agent

For review and automations share the same agent. You can ask it about your queue (for example, “what’s waiting in my For review queue from the renewal automation?”) and it only ever sees what you’re allowed to see. That makes fixing things collaborative: if an automation keeps producing drafts that aren’t useful, you can look at what it’s been sending for review, trace a draft back to the run that created it, and ask the agent to adjust the automation.

---

For how automations produce drafts in the first place, see Building automations. For the run model behind the “review happens after the run” constraint, see How automations work.