Page Workflows and Distribution Channels

Workflows is the third tab in the editor’s right rail, and unlike Page settings it is about what happens after the page goes live rather than what the page is. Everything on it is scoped to the one page in front of you: arming a channel here arms it for this page and no other.

When published: the five channels

The first section is headed When published, with a count beside it — 2/5 on — and a one-line statement of the trigger: Fires automatically when this page goes live. Below it, five rows, each a channel with a toggle.

The small gray line under each channel name is its state, and it says one of four things. When the channel is armed and carries a configured handle or audience, it shows that value. When it is armed with nothing specific stored, it reads Newsletter audience for email and Connected for the social channels. When there is no row for it at all, it reads Not connected. And when the channel is above your plan, it reads the plan you would need — Starter plan or Growth plan — in place of any of that.

A page has at most one row per channel, so switching a channel off and on again returns to the same row rather than accumulating duplicates.

On this page: the three behaviors

The second section is headed On this page, described as How this page shares itself with visitors and feeds, and holds three switches.

That last column is not a typo, and the section below explains it.

The feature image these posts would attach is the one set in Page settings; there is no separate image for sharing.

What your plan changes

The gate here is split across two tiers, and it bites only on the way up.

Below Starter, with nothing armed, the whole tab becomes the upgrade prompt — there are no rows to show.

The one asymmetry is worth stating plainly, because it is the opposite of what most gates do: a locked channel that is already switched on can still be switched off. If a workspace downgrades from Growth to Starter with Discord armed on forty pages, those rows stay visible and stay removable. A gate that trapped you in a state you can no longer manage would be a worse gate. When a feature is gated describes what that looks like elsewhere in the CMS.

Read-only access

The Workflows tab follows contact permissions rather than page permissions, because a distribution list is contact data. Without contact-write access the tab still loads and still shows you every row — the toggles simply do nothing, and a line appears under the behaviors:

You have read-only access to this page’s distribution settings.

Somebody who can edit and publish a page may therefore be unable to arm its channels. That is the intended split, and who can see what has the wider picture.

What is stored and what is sent

This is the section the page exists for, so it goes first in your head even though it comes last on the screen.

Here is exactly where a toggle goes today:

flowchart TD
    T["You switch a channel on"] --> R[("Stored distribution row<br/>page · channel · config · behaviours")]
    R --> UI["The Workflows tab reads it back<br/>— it is there on your next visit"]
    R --> AI["An AI client can read and change it<br/>over MCP"]
    R -.->|"not wired yet"| SEND["Email and social send pipelines"]
    R -.->|"not wired yet"| SITE["Share buttons on the built site"]

    classDef pending stroke-dasharray: 5 5
    class SEND,SITE pending

Two of those three consumers are real. The dashed edges are the seam, and they are drawn rather than described because a caveat sentence buried under a table is exactly how a customer ends up filing a bug against a feature that was never claimed to work. This limitation is collected with the others on known limitations.

Your AI clients treat these rows as ordinary data: they can list a page’s distributions and create or update them, which is genuinely useful for setting the same intention across many pages at once. Deleting a row is not exposed over MCP. The publishing and users tool group documents all three.

Where the working versions live

If you need something to actually go out when a page ships, three surfaces do real work today.

To send an email now, use the marketing email flow at sending a marketing email. That path builds a batch, resolves an audience and delivers it, which is what people usually mean when they arm Email blast here.

For the channel-level story — how release notes and auto-posting are meant to fit together, and which channels each plan includes — read release notes and auto-posting. That page owns the subject; this one owns the per-page switch.

For planning a launch across several pieces, campaigns and deliverables in Engage carry the same kind of honest boundary and are described at campaigns and deliverables.

Setting the toggles here anyway is not wasted: they are the record of what each page is meant to do when the send path lands, and they are stored per page in a form the product will read. Treat them as intent, and do the sending elsewhere until this page says otherwise. What your plan includes, either way, is at feature availability by plan.