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 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. That fallback is the source of the trap below.

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.

The auto-add rename trap

When you create a page in a bound documentation set, Leed adds a menu item for it automatically. That item’s name is the slugified title, and its title is the real one:

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

The CMS tree shows title when it exists, so the item reads correctly in the editor. The published sidebar renders name. The result is a navigation full of URL slugs, and the defect is invisible in the CMS — you only see it on the built site.

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 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 when the menu is saved, not when you drag. A rejected save changes nothing.

Building a large set one drag at a time is slow, and every rejection above costs a round trip. Writing the whole tree in a single call from an AI client is the practical alternative — MCP Tools: Site Structure covers update_menu_draft, which replaces the entire tree in one save and therefore validates the whole thing at once.