Email Campaigns
Review and release bulk email campaigns an agent has assembled, one recipient at a time.
Overview
Email Campaigns give a human reviewer a staged checkpoint between an agent assembling a bulk send and that send actually leaving your mailbox. An agent can build the recipient list, merge each person's data into a template, and attach files, but nothing goes out until you have stepped through the rendered result and cleared every row that needs your attention.
Two screens make up the feature:
- Campaigns list (
/campaigns) - every campaign you can see, with status, recipient count, who it sends as, and when it last changed. - Campaign review (
/campaigns/:campaignId) - the rendered per-recipient review screen where a campaign is actually approved.
Release itself (the button that sends the campaign) ships as a separate capability; this screen renders the release control in its gated state and explains what still blocks it.
Who can see a campaign
There is no separate campaigns permission to grant. A campaign is visible to the person
it will send as (SendAsUserId), and to anyone holding tenant:admin. If you don't see
a campaign you expect to, confirm you are the sender it was built for or hold tenant
admin rights.
The Campaigns List
Open Governance -> Live Operations -> Email Campaigns in the sidebar to see every
campaign you have access to. You can also press Cmd+K (Ctrl+K on Windows) and search for
"campaigns", or go straight to /campaigns.
| Column | Description |
|---|---|
| Name | The campaign's name |
| Status | Draft, Ready for review, In review, Releasing, Sent, Failed, or Cancelled |
| Recipients | Total recipient count |
| Sends as | The mailbox the campaign will send from |
| Last activity | Most recent update, or creation time if never updated |
Use the status filter chips to narrow the list. A campaign sitting in In review is called out deliberately - the list exists so a campaign an agent assembled and handed off is never allowed to sit invisibly unreviewed.
Click a campaign to open its review screen.
The Campaign Review Screen
Navigate to a campaign's row, or /campaigns/:campaignId directly, to review it.
1. The sender statement
The page opens with a single plain-language sentence: "These will send from
<address>, as <name>." This is deliberately the first thing on the page, above
everything else. The entire authorization model rests on you understanding these
messages go out from your own mailbox, under your own name - not the agent's. If either
the sending address or the display name could not be resolved, the banner says so
explicitly instead of showing a blank.
2. The summary bar
Below the sender statement, a summary bar shows recipient counts by bucket:
| Bucket | Meaning |
|---|---|
| Valid | Ready to send, no open issues |
| Flagged, unacknowledged | Has a safety finding that has not been individually acknowledged |
| Needs attention | Invalid and cannot be sent as-is |
| Suppressed | Excluded by a suppression rule (e.g. unsubscribe, bounce history) |
| Excluded | Removed from the send for another reason |
Click a bucket to filter the recipient table down to it. The bar also states plainly which count is currently blocking release - release stays disabled while any releasable row is invalid or carries an unacknowledged safety finding.
The counts you see while filtering are drawn from the recipient rows loaded on screen. The number that actually gates release comes from the server's own eligibility check, run fresh after every change you make. If the two disagree - for example another reviewer edited a row, or you have not loaded the full recipient list - the bar tells you and offers a refresh, rather than silently trusting either number.
3. The recipient table
A filterable, paged table of every recipient, with their status badge and any safety findings. Rows are never hidden by default: suppressed recipients are shown as suppressed, not filtered out of view, and suppression cannot be overridden from this screen.
Each row with a flagged finding carries its own Acknowledge control. There is intentionally no "acknowledge all" button. Acknowledging is a per-recipient act: this prevents bulk-approving a list from turning into a rubber stamp that never actually looks at what a merge produced for each person.
4. The rendered message panel
Selecting a recipient opens the actual message that recipient will receive - the merged
subject and body, not the raw template with merge tokens like {{first_name}} still
showing. Reviewing the template is not the same exercise as reviewing the output; the
merge step is where personalization mistakes actually happen, so this panel always shows
what would land in the recipient's inbox.
Rendered HTML bodies are agent-authored content and are rendered inside the sandboxed artifact viewer, the same isolation used for other agent-authored HTML in the console. They are never injected directly into the page.
Any files that will be attached for that recipient are listed alongside the message, in one of three explicit states: a list of attachments, an explicit "no attachments," or an explicit "the attachment list could not be read." None of these read as a blank - a blank attachment area could be misread as "nothing attached" when the real answer is unknown.
Use the stepper to move between recipients, or the "next needing a decision" control to jump straight to the next row that still needs your attention.
5. Releasing
The release control is visible but disabled until every releasable recipient is valid and every flagged finding has been individually acknowledged. Releasing a campaign - the confirmation flow and send progress - is a separate capability from review; this screen's job is to get every row into a state where release is safe to allow.
Recipient Statuses at a Glance
| Status | What it means for the reviewer |
|---|---|
| Valid | No action needed |
| Flagged, unacknowledged | Read the finding, then acknowledge that specific row |
| Needs attention | Cannot be sent; the row explains why |
| Suppressed | Will not be sent; shown for visibility, not editable here |
| Excluded | Will not be sent for another reason |
FAQ
Why can't I bulk-acknowledge every flagged recipient at once? By design. A bulk acknowledge button would let a reviewer approve a whole list without actually reading any individual row, which defeats the reason this screen exists. Each flagged row needs its own acknowledgment.
Why do I see the merge template instead of the finished message? You shouldn't - if a recipient's rendered subject or body is missing, the campaign has not yet been materialized for review. That is a distinct, explicitly labeled state, not a broken page.
A suppressed recipient looks wrong to me. Can I override it from here? No. Suppression is shown for visibility only and is not overridable from the review screen.
The summary bar's count doesn't match what I count in the table. Which is right? Trust the server-reported eligibility numbers; they are what actually gates release. Use the refresh control the bar offers when it flags a mismatch.