The Workflows tab is where a page declares how its publication should be announced: mail it to a list, post it to X or LinkedIn, drop it into a Discord channel. The toggles are real and what you set is stored against the page permanently. What does not exist yet is the step that acts on them — so this page is precise about the difference between an armed channel and a delivered message, because the interface is not.
Where it is
Open a page in the editor and look at the right rail. Five tabs — Assistant · Comments · Workflows · Analytics · Page settings — and Workflows is the third.
The tab has two sections. When published lists the five channels with a switch each and a count of how many are on. On this page holds three behavior switches that apply to the page rather than to one channel.
Reading the tab needs contact read access. Changing anything needs contact write access, whose minimum role is Content Publisher — a Content Writer sees the tab with every control disabled and a line reading “You have read-only access to this page’s distribution settings.” The rail itself, and the four tabs beside this one, are covered in page workflows; this page owns what the channels mean and what each one costs.
The email channel
The first row, Email blast, is the capability sold as release notes to email.
Switching it on creates one row against this page recording that the email channel is armed, together with whatever configuration you supply. A page has at most one row per channel, so arming the same channel twice updates the row rather than adding a second one. An armed row’s subtitle shows a short summary of its stored configuration, or Newsletter audience when there is nothing to summarize; an unarmed row on a plan that could arm it reads Not connected.
The social channels
X, LinkedIn, Bluesky and Discord are the four social rows. They behave identically to each other and differ from the email row only in what they cost.
Discord in this list is a channel name, not an integration. Nothing in Leed posts to a Discord server on your behalf.
| Channel | Stored key | Entitlement to arm | Minimum plan | What arming does today |
|---|---|---|---|---|
| Email blast | email | releaseNotesEmail | Starter | Records the setting. No mail is sent. |
| X | x | releaseNotesEmail + leadWorkflows + autoSocialPosting | Growth | Records the setting. No post is made. |
linkedin | releaseNotesEmail + leadWorkflows + autoSocialPosting | Growth | Records the setting. No post is made. | |
| Bluesky | bluesky | releaseNotesEmail + leadWorkflows + autoSocialPosting | Growth | Records the setting. No post is made. |
| Discord | discord | releaseNotesEmail + leadWorkflows + autoSocialPosting | Growth | Records the setting. No message is posted. |
Both entitlements are listed alongside everything else in feature availability by plan, and the prompt you get when a row is locked is decoded in when a feature is gated.
On-page behaviors
Three switches under On this page:
| Switch | Stored key | What it is meant to control | What it does today |
|---|---|---|---|
| Auto-share on publish | autoShareOnPublish | Broadcast to the armed channels when the page goes live | Stores the value. Nothing is broadcast. |
| Show share buttons | showShareButtons | Render social share controls on the live page | Stores the value. No site template reads it, so no control appears. |
| Include feature image | includeFeatureImage | Attach the page’s feature image to shared posts | Stores the value. Nothing shares. |
The three are stored together on the page’s primary channel row — the first armed channel in the order the rows appear, falling back to the email row. That produces one behavior worth knowing in advance: toggling any of these switches on a page with no armed channel silently creates an email row in the switched-off state to hold them. You will see the email row’s switch stay off, which is correct, but a row now exists where none did before. Changing a behavior is also part of the gated Starter surface, so the switches are inert below Starter even though they are visible.
Share buttons on your live pages, if you want them, are rendered by your site’s templates — see head and component partials. The switch here does not put them there.
What happens when the page goes live
Until it ships, announce a publication in two steps. Publish the page as usual — publishing and scheduling a page covers what going live actually triggers, and arming a channel is not part of it. Then send the announcement yourself: a blast from the composer to a contact group, described in sending a marketing email, and social posts by hand.
Setting the toggles now is not wasted. They are stored per page and survive, so a page armed today is a page already configured on the day the fan-out arrives. Just do not rely on them to reach anyone in the meantime. Planning outreach above the level of a single page has the same honest limit — campaigns and deliverables records intent rather than sending it.
Downgrading
The gates are deliberately asymmetric: they stop you turning things on, never off.
| Action | Gated? | Notes |
|---|---|---|
| Read the tab and its rows | No | on every plan, including Free |
| Arm a channel | Yes | the channel’s own entitlements |
| Reconfigure an armed channel | Yes | the existing row’s channel decides which entitlements apply |
| Change a behavior switch | Yes | Starter, the same floor as the email channel |
| Switch a channel off, and nothing else | No | a plain disable is never gated |
| Delete a row | No | on every plan |
That is why the tab does not simply disappear below Starter when rows already exist. A workspace that drops from Growth to Starter keeps its armed LinkedIn row visible and switchable-off, and a workspace that drops to Free keeps whatever it had. If nothing is armed at all there is nothing to clean up, and a Free workspace gets the upgrade prompt in place of an empty list.
The one thing this asymmetry cannot do is arm a channel again. Turning a locked row off is a one-way door until you are back on a plan that includes it.