Publish Reminders and the Must-Publish Model

One rule explains most of the surprises in the Leed CMS: saving is not publishing. Everything you change is stored the moment you change it, and stays private to your workspace until a deployment carries it to your site. Nothing is lost, nothing is at risk, and nothing is public. This page is the model. The Deploy tab is where you act on it.

Publishing is ungated — every plan, including Free, can publish and deploy as often as it likes.

The two markers you will see

Leed signals unpublished work with the same two elements everywhere, so learning them once is enough.

The amber dot

A small amber circle beside a changed item, carrying the tooltip “Must be published to be active”. It is one shared component used in every list, which is why it looks identical next to a label, a page type, a form, a team member, a search index and a settings card. The dot means one thing only: this item differs from what your site is serving.

The publish reminder

An amber banner in a screen’s header reading Unpublished changes — Publish, which links to the Deploy tab. It appears when two things are true at once: that screen has unpublished changes, and you hold the publish permission.

Where the markers appear

On Settings home, a dot sits on the card for any area with unpublished changes — General, Team members, Page types, Labels, and Search & autolinks — so you can see from the grid what is outstanding without opening anything.

Inside those screens the dot appears per row: beside a label in Settings → Labels, a page type in Page types, a member in Team members, a form in Settings → Forms, an index in Search & autolinks, and beside the affected fields in General. The form builder carries its own version — an Unpublished changes chip in the header of the form canvas that jumps straight to Deploy.

What actually collects in Pending changes

The Deploy tab’s Pending changes card is a checkbox list, and its membership is fixed. Exactly eight kinds of thing can appear in it, at two different granularities: five kinds list one row per item, and three list a single row covering everything of that kind.

A member with no name on record falls back to their email address, and failing that their user id. A deleted menu never appears, even if it was changed before deletion.

Settings (General) appears only when you change a field your site build actually publishes. Editing one the build never reads, such as the AI Image Theme Guide, saves without adding the row. Once the row is there it stays until a publish clears it: background updates such as a billing sync no longer clear it, and a change of plan tier adds it. Autolinks appears when any rule changes and also when you only reorder them, because the order is part of what gets published.

What is not in that list — and why

Four things people expect to find here are genuinely absent, and each is absent for a different reason.

A page never appears there. Publishing a page from the editor starts its own deployment immediately, or at its scheduled time if you scheduled it. See publishing and scheduling a page for its own required-field checks.

Template and layout files are not edited in the CMS at all. They live in your site repository and change through the Leed CLI, whose pushes go to your preview branch, not to the live site. Getting them live is a separate promotion. Preview site vs live site explains the two-branch model and promoting preview to live covers pushing it across.

Logo and favicon uploads publish themselves. Uploading a new logo or favicon in Settings commits it to your live site straight away, so there is nothing left to wait here and no row ever appears for it.

Dynamic CTAs are never published at all. They are served live from the API on every page view, so a change to one takes effect without any deployment.

Publishing a selection

You tick the items you want, not all of them. Leed groups your selection by the site each item targets, bundles every file change for that site into one commit, and creates one deployment per site tagged with the union of the reasons it carried. Each ticked item is its own unit: one that is no longer pending — a colleague published it first, say — is skipped and reported rather than blocking the rest, and if one kind of item fails to build, the others still publish.

Publishing changes walks the Pending changes card control by control, including what happens when you hold no publish permission.

Reading the reason badges

Every deployment in your history carries the reasons it was created for. These are the ones your own actions can produce.

Older deployments can carry badges nothing produces any more. Templates dates from when the CMS had a layout editor, and Dynamic CTAs is older still.

When your change is actually live

A deployment is a full rebuild of your entire site, not a patch of the pages you touched, and it takes a couple of minutes. Your change is public when that deployment reaches Active on the live column of the Deploy tab — not when you clicked Publish, and not when the build says it succeeded.

flowchart TD
    A[You change something in the CMS] --> B[Saved immediately, private to your workspace]
    B --> C{What kind of thing?}
    C -->|A page| D[Publishes on its own,<br/>now or on its schedule]
    C -->|Everything else| F[Waits in Pending changes]
    F --> G[You tick what is ready and publish]
    D --> H[One deployment per target site]
    G --> H
    H --> J[Full site rebuild]
    J --> K[Active — the change is public]

How publishing works traces that build end to end, deployment history and status explains what Active means and what to do when a build fails, and every deployment is a full rebuild explains why one small edit still costs the whole site.