Left Navigation Menu

The left menu is the documentation set’s sidebar, and it is more than a sidebar: it decides the reading order of the whole set, the breadcrumb trail on every page, the previous/next chain, and — because folder names become URL segments — where every page in the set lives. Editing it is editing the set’s structure.

It is an ordinary Leed menu with four extra rules enforced on it. Menus and the menu builder are free on every plan.

Where you edit it

Documentation menus live in the Design workspace, in its Documentation section, at /documentation/<menuId>. That section lists only menus bound to a documentation or API page type; ordinary site menus are in the Menus section beside it, and cannot be reached from here.

Expanding a set reveals its tree and a toolbar on the same row:

The tree marks each page with its status. A pencil, with the tooltip Unpublished changes, marks a page that is in draft, in revision or approved; an alarm clock marks a page that is scheduled to publish. An item whose page no longer exists carries an amber warning icon, Referenced page does not exist. The rail’s sort-and-filter button adds the same status pills the Pages library uses, so you can show only the drafts in a set; dragging is turned off while a filter is on, and the rail says No matches when no set has a page in the selected statuses. Pages that belong to a documentation or API set are edited only here — the Site section’s tree and page-type pills leave them out.

The tree editor itself — dragging, the gear dialog, the page picker — works identically for site menus, and Building and Editing a Menu documents it once.

Folders and pages

A documentation menu holds exactly two shapes of item, and the distinction is structural rather than cosmetic.

A folder is an item with no link and at least one child. It groups pages and nothing more. Any href you put on a folder is blanked on every save — the server strips it — so a folder can never be a link, in the editor or on the published site. Readers expand it to reach the pages inside.

A page item may not have children. Attempting to nest anything under a page is rejected outright:

A docs page item cannot have children — place pages inside folders instead

The rejection exists because the two rules interact badly: an item with both a page link and children would be treated as a folder on the next save, its href blanked, and the page silently dropped out of the navigation while its URL moved. Rejecting the shape is cheaper than explaining that afterwards.

Nothing in the code caps nesting depth, but one level — folder, then pages — is the shape the documentation layouts are built and styled around, and it is the shape this documentation set uses. Go deeper only with a build in front of you.

Ordering, expanding and hiding

There is no order field. The order of the sidebar is the order of the items in the tree, changed by dragging. Nothing in a page’s own settings influences it.

Expanded opens a folder by default for every reader, on every page of the set. Use it for the folder a new reader should land in; leave the rest closed so the sidebar stays short. The expand/collapse control in the toolbar is an editor convenience and has no effect on readers.

Disabled removes the item from the published navigation entirely. It is not hidden with CSS and it is not merely unclickable — the item is not emitted at all. In the editor it stays where it is, struck through, so a section can be pulled out of the navigation and put back without rebuilding it.

Menu item fields

Label, tooltip and icon

Two fields on a menu item look like the same thing and are not.

• name is the visible label. It is what the sidebar renders. Double-click an item in the tree to change it.
• title is the hover tooltip. It becomes the HTML title attribute. The gear dialog calls it Tooltip.

The CMS tree displays title when there is one and falls back to name. Renaming an item by double-clicking it sets its name and clears its title, so after a rename the tree, the sidebar and — for a folder — the URL segment all follow the new name.

Icons are Font Awesome classes and they live on the menu item, not on the page — there is no icon field on a page anywhere in Leed. Picking an icon in the CMS clears any icon color you had set, so if you are writing menu items through the API, set the icon and its style together in one call or the color is lost.

Auto-added menu items

When you create a page in a bound documentation set, Leed adds a menu item for it automatically, with the page’s title as both its name and its title:

{ "name": "What a Documentation Set Is", "title": "What a Documentation Set Is", "href": "pageid:1179fa68-…" }

The item lands at the top level of the menu unless the page is created into a folder: through the API or an AI client, pass menuFolderId (with menuIcon and menuIconStyle if you want an icon) when you create the page. Adding many pages at once is safe — each one gets exactly one menu item, however many are created in parallel.

The one-menu rule

A documentation page may appear at most once, in exactly one documentation left menu, across the whole workspace. A menu save that breaks either half is rejected with a 409 and the offending page ids.

Adding the same page twice to the menu you are editing:

Duplicate page in menu: the page is already in this menu, so the add was rejected — a page may only be referenced once, in a single docs menu

Adding a page that already lives in a different documentation set’s menu:

A docs page may only be referenced once, in a single docs menu

The rule is not tidiness. A page’s URL is derived from its position in the menu, so two positions would mean two URLs for one page, and the breadcrumb and previous/next chains would have no defensible answer for where it sits. If a page genuinely belongs in two places, link to it from the second place in the body rather than adding a second menu entry.

The rule also runs the other way: every page of a set must stay in the set’s menu. A change that would leave one out — removing its item, removing a folder together with its contents, or rewriting an item’s link — is refused with a 409 naming the pages. Move the page to another folder, remove the folder with its children promoted into its place, or delete the page itself. Marking an item Disabled is not a removal and is still allowed.

The navigation lock

Navigation Menu Locked is a checkbox on the page type, beside Content Locked. Ticking it freezes the set’s URLs: no reordering, no moving a page between folders, no renaming a folder, no removing an item. The Add Folder and Add Page controls disappear from the set’s toolbar while it is on, and the set’s name in the tree carries a lock icon with the tooltip “Navigation menu locked — unlock in Settings → Page Types to reorder, move, or rename.”

Presentation edits still work: icon, tooltip, expanded, disabled, and the display label of a page leaf.

A move attempted in the CMS is refused, and one through the API returns a 403. Both carry the same message, naming the page type and the exact checkbox to uncheck:

Cannot change navigation: the 'Documentation' page type's navigation is locked. An Administrator or Content Publisher can uncheck Navigation Menu Locked in Settings → Page Types.

The lock lives on the page type alongside Content Locked — see Configuring a Page Type.

What readers actually see

The published sidebar is not a copy of the tree. Four rules decide what survives the build.

The third row is the one that costs an afternoon. An unpublished page is silently missing from the navigation — no gap, no placeholder, no warning. A half-published set therefore looks like a set with missing pages rather than a set with pending publishes. Publish everything before you judge the navigation; Publishing a Documentation Set is the order to do it in.

Two things not to do after your first publish

Do not rename the menu. The published menu file is keyed by the menu’s name, and publishing merges into it without ever removing a key. A rename writes a new key and orphans the old one permanently — the site keeps rendering from whichever key its templates ask for, and you have two menus in the file with no way to remove the stale one from the CMS.

Do not reorganize folders casually. Renaming or moving a folder does more than reorder the sidebar: it moves every page beneath it, changing their URLs. Folders Set Your URLs is the page to read before your first reorganization, and it explains what is committed immediately and what is staged until each page’s next publish.

Docs-menu save rejections

Every rule on this page is enforced by the server each time the menu changes. The editor sends one change per gesture — a drag, a rename, an add, a removal — and the server checks the menu that change would produce. A rejected change writes nothing.

From an AI client or the CLI, a menu is edited one item at a time, never by sending the whole tree. MCP Tools: Site Structure covers set_menu_item_fields, add_menu_item, remove_menu_item, move_menu_item, reorder_menu_items and update_menu_fields; add_menu_item takes a whole subtree, so a folder and its pages go in with one call. The CLI has the same operations under leed settings menu.