Rename a label, add a form, change your site description, edit a menu — and the CMS saves it instantly. Your site does not change. The saved edit waits in one place: the Pending changes card, on the right-hand side of the Deploy screen.
The card says as much itself: “Changes to your site’s settings and configuration — menus, forms, labels, page types, team members, and more — that haven’t been published yet. They won’t take effect on your site until you publish them.” Everything in that list is saved and safe. None of it is on your site.
What actually appears in this list
The list is narrower and more specific than “things I have changed”. Exactly eight kinds of thing can appear in it, and their granularity is not uniform — which is the detail people get wrong.
Labels, page types, team members, forms and menus appear one row per item. Rename two labels and you get two rows, and you can publish one without the other. General settings, autolinks and search indexes each appear as a single row covering everything of that kind — one row, all of it, published together.
| Item | One row per… | Label you will see | Where you changed it |
|---|---|---|---|
| Labels | each changed label | Label: <name> | Settings → Labels |
| Page types | each changed page type | Page type: <name> | Settings → Page Types |
| Team members | each changed person | User: <first last> | Settings → Team Members |
| Forms | each changed form | Form: <form name> | Design → Forms |
| General settings | one row for all of them | Settings (General) | Settings → General |
| Autolinks | one row for all of them | Autolinks | Settings → Automations |
| Search indexes | one row for all of them | Search Indexes | Settings → Search Indexes |
| Menus | each changed menu | Menu: <name> | Design → Menus |
Two details in the label formats. A team member with no name falls back to their email address, and then to their internal id — so a row reading User: someone@example.com is normal, not an error. A form saved without a name shows as Form: (unnamed).
A deleted menu is filtered out, so a menu you removed and had never published does not sit in the list forever waiting to be published. Deleting a documentation page works the other way round: Leed removes the page’s entry from its set’s left navigation menu, so that menu then appears here as a pending change of its own.
What never appears here
Several things are absent, for genuinely different reasons. Knowing which is which saves you looking for a row that is never going to exist.
| Thing | Why it is not here | Where it happens instead |
|---|---|---|
| Pages | They have their own editorial lifecycle and their own deployment | The page editor’s Publish, or a scheduled slot |
| Template and layout files | They live in your site repository, not in the CMS | A developer’s leed site push, straight to the preview site |
| Access overrides, editor-formatting toggles, required-field rules, page-type locks | They change the CMS, not the built site — there is nothing to publish | They take effect immediately |
| Logo and favicon | They are part of your general settings | Folded into the Settings (General) row |
| Dynamic CTAs | They are served live to your site on every request and are never built into it | Settings → Dynamic CTAs, effective immediately |
Template work never queues here: it arrives as files on the preview site and reaches live by promotion. And editor-formatting toggles and required fields change the CMS rather than the site, which is why they never queue here either; what each page type lets you format covers those.
Publishing a selection
Tick the rows you want. A Select all (N) header above the list takes everything at once, and its checkbox shows an indeterminate state while only some rows are ticked.
The button beneath the card relabels itself as you go:
| Button reads | State |
|---|---|
| Select changes to publish | nothing ticked — the button is disabled |
| Publish 2 to live site | two rows ticked, ready |
| Publishing… | the request is in flight |
A Publish started toast confirms it, the ticks clear, and the rows disappear from the list once the commit lands. A new row appears in the Live site history column.
Every row you tick is published on its own merits, so one bad row never holds the others back. A row that is no longer pending by the time you click — a colleague published it a moment earlier, say — is skipped, and a row that could not be prepared is left unpublished. Either way the rest go out, and the toast turns into an error that names what did not: Skipped, no longer pending: … or Failed, not published: …. A failed row stays ticked so you can try it again; a skipped one drops out of the list.
The resulting row is one deployment with several reason badges, which is how to read that row. A menu is a special case worth knowing about: publishing one commits the entire tree, including any folder moves you staged while editing it — what publishing a menu commits.
The same list is available outside the browser. leed settings pending prints it with each row’s id, and leed settings publish <ids...> publishes the rows you name, or every one of them with --all; it exits non-zero if any row failed, so a script notices. Over MCP, list_pending_changes and publish_pending_changes do the same. Each route publishes row by row exactly as the card does, and reports what it skipped and what failed.
The amber dot, everywhere else in the CMS
You will meet this list’s contents long before you reach the Deploy screen. Anywhere in the CMS that shows a label, a page type, a form, a team member or a search index with unpublished edits, that row carries a small amber dot. Hover it and it says “Must be published to be active”.
It is one shared marker with one meaning, wherever it appears: this is saved, and it is not on your site. The must-publish model is the mental-model page for it.
At the top of a settings screen with unpublished changes, a matching amber strip appears reading Unpublished changes — Publish, which links straight here.
That strip is rendered only for people who can actually publish. A Content Writer editing a label sees the amber dot beside the row but no reminder strip — that is by design, not a partial page load.
When the list is empty
The card reads:
Nothing pending — everything you’ve edited is published.
That statement is precise, and narrower than it sounds. It means nothing of those eight kinds is waiting. It says nothing about:
- pages scheduled for a future slot — those are listed separately, under Scheduled for publishing on the Live site card;
- whether your preview site is ahead of live — file changes never appear here, so preview can be several template edits ahead with this list empty;
- whether the last deployment succeeded — check the history columns for that.
If you cannot tick anything
Publishing needs the deployment:publish privilege, which comes with the Content Publisher role and above. Without it, the card renders the list — every row, fully readable — with no checkboxes, no select-all header and no button.
Changing a team member’s role is itself a pending change, because author details are published to your site — see managing team members. The same is true of labels, page types, forms and your general site settings: edit freely, publish deliberately.