Legacy and runtime-only tiles
Some tile machine types remain on legacy landing pages even though the dashboard picker no longer offers them for new work. Separate actively authored tiles from historical runtime behavior when diagnosing odd guest screens.
Do not promise authoring UI for legacy types unless product management explicitly re-enables them. Default guidance is to rebuild using supported modules (faq, text, nested landing pages, and similar).
Examples (non-exhaustive)
Older deployments occasionally retain modules such as specialized content routes, deprecated timetable widgets, or experimental translator shortcuts. Guests might still reach those URLs if published records remain, even though teams cannot create fresh copies from the current catalog.
Operational guidance
Spotting legacy tiles
If an editor fails to open a tile or guests see an unfamiliar route, check whether the tile predates the current picker catalog. Historical modules sometimes lack modern validation entirely.
Support phrasing
“This tile type remains only for legacy deployments; publish new experiences using the supported tiles available today.” Offer rebuild guidance (faq, text, nested landing pages, etc.).
Information to gather internally
Capture tile identifiers, landing slug, approximate creation timeframe, and screenshots demonstrating guest versus authoring discrepancies before requesting engineering assistance.
Related: Reference tile types, Web app model.