Governing the Multilingual Breadcrumb: Keeping Folders, Pages and the List in Sync
SPFx Technical Deep Dive · Part Two
The maintenance problem the breadcrumb mechanism creates
The multilingual breadcrumb solves the display problem: folders have no native translation mechanism, so a SharePoint list bridges the gap, giving every governed folder a translated label and a link to a real landing page in each language.
That mechanism works, but it introduces a dependency that has to be actively maintained. Every folder intended to appear as a clickable, translated breadcrumb destination needs three things to exist together: an English landing page, a French landing page, and a row in BreadcrumbTranslations tying the two together. Nothing in SharePoint enforces this automatically. A folder can be created at any time, by anyone with edit rights to the Site Pages library, with no prompt, no reminder, and no record that a breadcrumb entry is now expected.
Left alone, this drifts. New sections get added, their folders sit without landing pages or list entries, and the breadcrumb silently falls back to an untranslated raw folder name, or a link into SharePoint's default folder browse view rather than real content. Neither is broken exactly, the fallback logic in the breadcrumb component is deliberately safe, but neither is the intended experience either, and nothing surfaces the gap unless someone happens to notice it while browsing.
This is a governance problem, not a code problem, and it needs a governance answer: something has to notice a new folder the moment it's created, tell the right person what's now expected of them, and confirm later whether that expectation was actually met.
Two automated flows, working together
Two Power Automate flows handle this, each with a distinct, narrow responsibility.
Flow one fires the moment a folder is created, and does two things immediately: it writes a placeholder entry into BreadcrumbTranslations so the gap is visible in the governance data right away, and it emails the folder's creator with exactly what's expected of them, including the precise URLs their landing pages need to exist at.
Flow two runs on a daily schedule, checking every incomplete entry against reality: does a page now exist at the predicted location? If so, it promotes that entry from placeholder to live, no manual list editing required. If a stub has sat unpromoted for too long, it escalates with a follow-up reminder rather than staying silent indefinitely.
Together, they close the loop the breadcrumb mechanism itself can't close on its own: creation triggers the request, and a recurring check confirms whether the request was fulfilled.
Why the predicted paths live in separate columns first
BreadcrumbTranslations carries two additional columns beyond the ones the breadcrumb component itself reads: PredictedFolderPath and PredictedFolderPathFR.
This separation matters. The breadcrumb component's fallback behaviour depends on FolderPath and FolderPathFR being genuinely empty until a landing page is confirmed to exist, that's what keeps a visitor from ever landing on a broken link. If the predicted URL were written directly into the live FolderPath column at the moment a folder is created, before anyone has actually built the corresponding page, the breadcrumb would immediately start linking to a page that doesn't exist yet, a 404 in front of a real visitor.
Writing the prediction into a separate, unread-by-the-breadcrumb column solves this cleanly. The prediction is visible and useful, both as instructions in the reminder email and as a record for the daily check to act on, without ever being live. Only once a page is confirmed to genuinely exist at that location does the value get copied into the real FolderPath or FolderPathFR column, and only then does the breadcrumb start using it.
How a new folder's expected page locations are predicted
Landing pages follow a consistent, predictable pattern: a page sits as a sibling of the folder it represents, in the same parent directory, with the French version living in an fr subfolder alongside it. A folder named NewSection created inside IT is expected to be represented by:
| Language | Predicted URL |
|---|---|
| English | /SitePages/IT/NewSection.aspx |
| French | /SitePages/IT/fr/NewSection.aspx |
Because this pattern is fixed, the expected locations can be computed the instant a folder is created, from its name and parent path alone, no guessing required, and no need to wait for a human to specify where the pages should go.
Flow one: on folder creation
Triggered whenever a new item is created in the Site Pages library, filtered to folders only.
On trigger, the flow:
- Computes the predicted English and French page URLs from the new folder's name and path
- Creates a new item in
BreadcrumbTranslations:FolderNameset to the folder's name,LabelENdefaulted to a readable version of that name,LabelFRset to a visible placeholder so it reads as obviously incomplete rather than silently wrong, and both predicted-path columns populated.FolderPathandFolderPathFRare left blank - Emails the folder's creator directly, laying out exactly what's needed: build an English landing page at the predicted URL, translate it to French using SharePoint's native Translate action so the translation lands at the predicted French URL, and update the label columns on the entry already waiting for them in the list, with a direct link to that entry included
Nothing about this flow depends on the creator acting quickly, or at all. The stub entry it creates is immediately visible in the list as incomplete, which is itself useful, a governance report run at any point can see exactly which folders are missing their pages, without needing to wait for flow two to run.
Flow two: daily promotion check
A scheduled flow, running once a day, that reviews every BreadcrumbTranslations entry where FolderPath or FolderPathFR is still blank but a predicted path exists.
For each incomplete entry, the flow checks whether a page now actually exists at the predicted English and French locations. Where a page is confirmed to exist, the flow writes that URL into the corresponding live column, FolderPath or FolderPathFR, promoting the entry from placeholder to fully functional, with no manual list editing required from anyone. Where a page still doesn't exist, the entry is left as is, and checked again on the next run.
Entries that remain incomplete well beyond a reasonable window, long enough that the original reminder has plainly been missed rather than simply not yet actioned, trigger a follow-up notification rather than continuing to check silently forever. This is what keeps the mechanism honest over time: a folder isn't allowed to sit permanently in limbo without anyone being told twice.
What this achieves
Between the two flows, the manual maintenance burden that the breadcrumb mechanism would otherwise place on content owners is reduced to exactly one task: creating a landing page in each language, at a location the system already tells them. Everything else, the list entry's existence, its eventual promotion to live, and the visibility of anything left incomplete, happens without anyone needing to remember a separate governance step or maintain the list by hand.
The result is a breadcrumb system that stays accurate as the site grows, not because everyone remembers the process, but because the process doesn't depend on anyone remembering it.