Shared navigation extension

The problem

Every intranet site wants a menu reflecting its own structure. The usual options are a menu maintained by hand per site, which drifts and which nobody updates, or a bespoke component per site, which means a separate codebase to patch for each one when something breaks.

What I did

One application customizer, deployed once, builds each site's menu in the browser from that site's own pages library: title, parent, sort order and icon. The menu is data owned by the site owner. Adding a page to it is filling in two columns; reordering is changing a number. No release, no ticket, no developer.

A colleague started it in 2021; I have been its principal developer since 2022. I replaced the first, flat pass with the recursive tree, onboarded the sites since then, including the one the legal knowledge-base migration depends on, and fixed rendering defects, including one that would have duplicated 111 menu entries on a newly onboarded site, caught before it shipped. Matching is by longest URL prefix, so other configured entries serve a wider set of department sites.

One onboarding took four changes, three of which shipped before the menu appeared, with no error message at any point. The extension simply rendered nothing. The fix that mattered was a fallback placeholder for site templates that lack the preferred one, so a missing injection point now produces a menu instead of a silent blank.

A decision and its cost

Parents are matched by title, not by identifier, so a site owner types a page name they can see instead of looking up an internal ID. The cost is that two pages with the same title are ambiguous and renaming a parent orphans its children. That is robustness traded for usability, made knowingly for an audience of non-technical site owners, and the mitigation is a convention, not a constraint.