Campaigns and Deliverables

With that established, here is what the planner is genuinely good at.

Two ways in

Creating a campaign

The + button in the left panel opens the create form, as does /engage/campaigns/new. Creating needs contact:write, whose minimum role is Content Publisher.

The form asks for three things: a Campaign name, a status — draft, scheduled or active — and a Subject line. Preview text is not on the create form; you add it inline afterwards.

The list groups every campaign under Campaigns · N, showing the name, the subject line (or —), and a status dot — gray for draft, amber for scheduled, green for active. Sorting by signal puts active campaigns first, then scheduled, then drafts. Search matches the name and the subject.

The builder strip

Across the top of a selected campaign sit five steps that tick themselves from real data. None of them is a wizard — you can work in any order, and a tick is a description rather than a gate.

The last two depend on you changing the status by hand, which is why a campaign with a full, dated, approved sequence can still show two unticked steps. Approving a deliverable flips the status to scheduled and ticks Schedule; only you can tick Live.

Objective

Two cards: Subject and Preview text. Both edit in place and save on their own — click, type, click away. They are the campaign’s stated intent and the seed for anything Chat drafts against it; because nothing sends, they are not yet an email header.

Audience

A campaign targets personas and accounts. Both are edited inline: each card lists the current targets with a remove control and an Add persona… / Add account… picker beneath, and every change replaces the whole target set on the server.

There is no contact-level targeting and, importantly, no recipient count anywhere. The audience stores target ids and never resolves them to people, so nothing on this screen will ever tell you that a campaign reaches 412 contacts. Readers look for that number; it is not there and it is not hiding.

What targeting does do today is real but modest. It fills the Campaigns facet on each targeted persona, so somebody reading a persona can see what is aimed at it. It gives the same for a targeted account. And it gives Chat a concrete audience to write against when you ask it to refine the plan.

Deliverables

The Content & sequence list is the campaign’s actual plan. Each deliverable carries a title, a type, a scheduled date, an ordering number, an optional detail note, an optional assignee, and an approval state. Rows sort by order, then by date, and each shows its type icon, its title, type · date, and its approval pill.

Every deliverable must also reference exactly one real thing — a page, a deployment or an email batch. That rule is type-agnostic and enforced on write: a social or event deliverable still has to name one of the three, and supplying none, or two, is a 400 reading “exactly one of pageId, deploymentId, or leadBatchId is required”.

The calendar treats all seven the same way: it shows the title, the date, the deliverable type and the approval state. It does not render a different shape per type.

Approving a deliverable

Approval is a separate privilege — contact:publish — and there are three states in the data model.

The rejected state is real enough to have a pill, and there is currently no way to reach it: the approve endpoint is the only writer of the column, and it only ever writes approved. If you want an item out of a plan, delete it.

What each action needs

Every one of those permission checks resolves overrides against the contact resource specifically, so an override that elevates somebody on a page or a label does not satisfy a campaign route. Below Growth, the routes answer 402 rather than 403 — but only after the permission check has passed, so a reader without contact:read gets a 403 on a Growth workspace and on a Free one alike.

How this reaches the Plan calendar

Every deliverable whose date falls inside the week you are looking at appears on the plan calendar, alongside scheduled page revisions and deployments. Approval state is not a filter — a draft deliverable is on the calendar too, carrying its Draft pill, which is precisely what makes the review strip appear.

That strip is the campaign’s real workflow. A campaign holding any draft deliverable prompts anyone with contact:publish to review and approve, and approving from there is what moves the campaign to scheduled.

Performance

The Performance facet rolls up genuine per-recipient send data: it collects the email batches referenced by this campaign’s email-type deliverables and sums their recipients, sends, opens, clicks, unsubscribes and bounces, showing open and click rates against sends. Unsubscribes and bounces appear only when they are non-zero.

Those numbers come from the same open and click trackers as any other send, described in tracked links and open tracking.

The rest of the facet rail

• Plan — Deliverables, Approved and Draft counts, the campaign status, and an approval-progress bar reading N% approved. Empty until a deliverable exists.
• Schedule — every dated deliverable in date order. Empty, it reads Nothing scheduled yet.
• Channels — the distinct deliverable types present, as chips. It is a one-glance answer to “is this actually multi-channel?”
• Actions — Refine plan with Leed, which opens Chat with a prompt naming the campaign and asking for an objective, an audience and a sequence; and Duplicate campaign, which really does create something: a new campaign named (copy), in draft, carrying the subject and preview text. It does not copy the audience or the deliverables, so a duplicate starts with an empty plan.
• Leed suggests — one of three fixed sentences, chosen by counting deliverables and approvals. It is written by an if statement, not by a model, and it says either draft a first piece, N deliverables still need approval, or all deliverables are approved.

Deleting a campaign

Delete sits in the header and needs contact:write. It removes the campaign row and its audience targets.

Campaigns from an AI client

Most of the campaign surface is reachable over MCP, under the same contact:* permissions and the same Growth gate as the screen:

Three more exist but are assistant-only rather than MCP-visible, because each is destructive or an approval: delete_campaign, approve_campaign_deliverable and delete_campaign_deliverable. An external client can plan a campaign for you; it cannot approve or dismantle one. The campaigns and personas tool reference has the argument shapes, and get_plan_calendar — the one that keeps working below Growth — is documented with the publishing and distribution tools.

The seam, drawn

flowchart LR
    C["Campaign<br/>name · status · subject · preview"] --> A["Audience<br/>personas + accounts"]
    C --> D["Deliverables<br/>title · type · date · order"]
    A -.->|"fills the Campaigns facet<br/>no recipients resolved"| P["Persona / Account"]
    D --> AP{"Approved?"}
    AP -- "draft" --> CAL["Plan calendar<br/>with a review strip"]
    AP -- "approved" --> CAL2["Plan calendar<br/>campaign moves to scheduled"]
    D -->|"email-type deliverables only"| PERF["Performance facet"]
    B["Email batch actually sent<br/>from the Email surface"] --> PERF
    CAL2 -.->|"NOT IMPLEMENTED — nothing here sends"| SEND["Email send"]
    G["Contact group"] --> B
    style SEND stroke-dasharray: 5 5

The dashed edge is the whole point of the diagram. Everything to its left works; the arrow itself does not exist. To email the people a campaign is aimed at, build a contact group and send to it from the email surface — the two halves meet only if you link the resulting batch to an email deliverable by hand, and even then the link is for reporting.