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 seven kinds of thing can appear in it, at two different granularities: five kinds list one row per item, and two 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.

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.

A layout file commits the moment you save it in the Layouts editor — but to your preview branch, not to the live site. Getting it live is a separate promotion. Preview site vs live site explains the two-branch model and promoting preview to live covers pushing it across.

Search indexes and logo or favicon changes are real, and they do get published — they simply do not get rows of their own. Both ride along inside Settings (General), so publishing that one row carries them.

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.

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.

Search Indexes and Logo/Favicon are the two badges you can see on a deployment but never as a row in Pending changes — both are published as part of Settings (General). You may also encounter a Dynamic CTAs badge on a very old deployment; nothing produces it any more.

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 -->|A layout file| E[Commits to preview<br/>the moment you save]
    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
    E --> I[Preview site rebuilds]
    H --> J[Full site rebuild]
    J --> K[Active — the change is public]
    I --> L[Promote preview to live when ready]
    L --> H

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.