Publishing and Scheduling a Page

One button in the top-right corner of the editor does all of this, and the first thing to understand about it is that it is a scheduling control even when you mean “now”. Clicking Publish does not push the page live; it asks you when the page should go live, and Leed takes it from there.

Before you can publish

Three things have to be true.

You need publish permission on this page. Edit permission is not enough: a Content Writer can create pages, write them and hand them over, but the Publish button is not rendered for them at all. Publish permission comes from your role — Content Publisher and Administrator carry it — or from a per-page, per-label or per-page-type override that raises your access on this particular page. Roles and permissions explains both halves.

The page type’s required fields must be filled. Which fields those are is a property of the page type, not of the page — it is configured once for the whole type and then applies to every page in it.

The page must not be private. A private page has no Publish button, and the server refuses the attempt with a 409 and the message Cannot publish private page <id>. if something tries anyway. Private is set through the API rather than in the CMS; private pages covers what it does and why.

Missing Required Fields

If a required field is empty, clicking Publish opens a dialog instead of the date picker:

Missing Required Fields Before publishing, please provide the following in the page settings panel:

…followed by a list of exactly what is missing. Fill them in the Page settings panel and click Publish again. There are four fields a page type is able to require:

A page type’s Form setting has three values, and only Required blocks a publish: Not allowed hides the field, Optional offers it without insisting. Documentation page types require a Summary by default, which is the one most people meet first.

Publishing

Click Publish and you get a small dialog headed Publish Page, described as Schedule this page to go live., with a single date-and-time picker.

The picker opens on the next quarter hour in your browser’s own timezone. At 10:07 it offers 10:15; at 10:15 it offers 10:30. This is the single most consequential behavior on the page:

You can move the time earlier within today — the time field is free — but the calendar will not let you pick a day before today. A time already in the past is perfectly valid and is picked up by the very next check, which is the closest thing to “now” the system offers.

When it really goes live

Leed checks for due publications every minute, and it starts the build about three minutes ahead of the slot you chose. That head start exists so the page is live at its slot rather than a couple of minutes after it: the site is built while the clock runs down, and the new version is switched on when the moment arrives.

Two consequences follow. A publish scheduled for 09:00 begins building around 08:57 — so a last-second edit at 08:58 will not be in it. And a publish scheduled for a time in the past starts building on the next tick of the minute, which is why “now” behaves the way it does.

Scheduling for later

Nothing changes about the flow when you pick a future time; you use the same dialog and the same button. What changes is the aftermath. The page’s status becomes SCHEDULED with a violet chip, the page locks so nobody can quietly change what is about to go out, and the button in the header stops saying Publish and starts saying Scheduled for June 3, 2026 9:00am.

Nobody needs to be online, logged in, or anywhere near a browser when it fires. Your whole team can be asleep.

Manage Schedule

That Scheduled for… button is itself the control. Clicking it opens Manage Schedule — Change the scheduled publish time or unschedule this page to resume editing — with the same picker and two actions.

Change time re-schedules to the new moment. It stays disabled until you actually move the picker, so you cannot re-submit the same time by accident.

Unschedule cancels the commitment and unlocks the page for editing. Where it lands depends on the page’s history: a page that has never been live goes back to DRAFT; a page that has been live before goes back to IN REVISION, with the currently published version still serving your site untouched.

Target Date is a plan, not a commitment

Page settings has a date field near the bottom of the content group. On a page that has never been published it is labeled Target Date; once the page has been published it is labeled Published Date. It is the same stored value under both labels, and setting it publishes nothing and schedules nothing.

What it drives is the calendar. Your target date is where the page shows up on the Plan tab, so the team can see what is intended for when. A scheduled page overrides it there — a real commitment outranks a plan.

One behavior surprises people: when you revise a published page, the new revision is given a target date one week out, on purpose, so work in progress lands on the calendar as upcoming rather than sitting in the past beside the date the old version went live. Move it if the plan is different.

Republishing

On a page that is already live the button reads Revise, not Publish. You revise, edit, and then publish again — and the second publish is an ordinary publish, quarter-hour default and all. Revisions, versions and reverting covers that cycle and what the version number is counting.

Here is what the button does in every state:

What publishing sets in motion

The chain from your click to a changed website is four links long, and knowing it turns “I clicked Publish and nothing happened” into “the build is on step two”.

1. Your page — and every other page in your workspace due in the same minute — is committed to your site repository in one commit.
2. A deployment row appears on the Deploy tab.
3. Your whole site is rebuilt from that commit.
4. The new version is activated, at the moment you scheduled.

sequenceDiagram
    autonumber
    actor You
    participant Leed as Leed
    participant Repo as Your site repository
    participant Deploy as Deploy
    You->>Leed: Publish, scheduled for 09:00
    Leed-->>You: Status becomes SCHEDULED and the page locks
    loop every minute
        Leed->>Leed: anything due within the next 3 minutes?
    end
    Note over Leed: 08:57 — the page is due
    Leed->>Repo: one commit carrying every page due at 09:00
    Leed->>Deploy: a deployment row appears
    Deploy->>Deploy: rebuild the entire site
    Note over Deploy: 09:00 — the slot arrives
    Deploy-->>You: the new version is activated and live

Two things authors ask about, both visible in that picture. It takes on the order of a couple of minutes, because every deployment is a full rebuild — publishing one typo fix regenerates every page, the search index, the feeds and the sitemap. And other people’s pages ride along: anything scheduled for the same minute is committed and built together, so a colleague’s page can go live in “your” deployment. That is by design, not a bug, and it is why the Deploy tab shows deployments rather than publishes.

Watch it happen on deployment history and status; if it goes red, when a deployment fails is the page that reads the error for you. The pipeline side of scheduling, including the build-ahead window, is described from the deployment’s point of view on scheduling and automatic publishing.

Review and approval

This section exists to save you a search. Leed does not enforce an approval step on a page. There is a Content Approver role, there is an Approver column on labels and page types, and there is an APPROVED status in the data model — but no control anywhere in the CMS moves a page into approval, and nothing requires a page to have passed through it before it can be published.

What review looks like in practice is two real things used together:

• Suggesting mode, where a reviewer’s edits are recorded as accept-or-reject proposals rather than applied, and comments for the conversation around them.
• Publish permission as the gate. The person who signs off is the person who holds it. Give writers edit access and reserve publish for the people whose job it is, and you have a review step enforced by the only mechanism that actually enforces anything here.

Deleting a published page is also a publish

Taking a live page down is not a separate operation with its own timing. Deleting a published page goes through the same publish path: the removal is committed, a deployment runs, and the page stops existing on your site when that build activates — the next check picks it up, so it behaves like publishing “now”.

Because the URL is already live, the delete dialog will not let you leave a dead link behind. It requires either a redirect target — another page readers land on instead — or the Show “404 Page Not Found” instead of redirecting checkbox, ticked deliberately. It also lists every menu the page appears in and removes it from them as part of the same operation.

One asymmetry to expect: the Scheduled for publishing panel on the Deploy tab lists pages waiting to go live and deliberately never lists pending deletions. A queued deletion is invisible until its deployment appears. The full flow, including what happens to the page’s redirects, is on Managing Pages.

Once the page is live, arming how it announces itself — an email blast, a social post, share buttons on the page — is a separate per-page decision on the Workflows tab, which is honest about which of those actually send today.