Skip to content

design

Atlas’s UI for the Regional Facility Manager (South-West) persona. This is the design a regional manager sees when they log into Atlas Facilities. The region sits between the Facilities PM (whole estate) and the Facility Manager (one cluster) — see the PM PRD §12.

Live interactive prototype: /products/atlas/flows/facilities-regional-manager/ — the canonical Regional Facility Manager flow as a single-file HTML demo.

Name Regional Facility Manager (South-West) · prototype persona Tunde Bakare
Audience The regional owner of several facility clusters
Surface Atlas (web, desktop-first 1440px)
Auth context Internal employee SSO; region-scoped — reviews and forwards, no estate-level config; SOPs read-only
North star Regional Facility Health — share of the region’s sites in a Healthy state
  1. Monitor Regional Facility Health and clear the needs-attention clusters
  2. Drill into any cluster (health check, sites, escalations) and any site’s Record
  3. Review escalated issues and forward to the PM, or take them on in region
  4. Review requests and forward to the PM, or decline in region
  5. Keep equipment, contractors and per-cluster SOP acknowledgment in view
Sidebar surface What it does
Overview Regional Facility Health + open issues / pending requests / out-of-service equipment KPIs, a Clusters roll-up table (drill-in), and a cross-cluster activity feed.
Clusters The region’s 3 clusters → a cluster detail page (hero, KPIs, a Cluster-health check, its sites table, and escalations pending your review).
Facilities All 14 region sites, filterable by cluster + type, → a read-only per-site Record (Overview health check + Personnel / Equipment / Contractors / Issues / SOPs tabs).
Facility Issues The region issue queue with .filt-select status/cluster filters in the .tbl-card-head, opening an issue details page (.pg-back + .pg-title-row + .rec-grid): status + severity, details, an immutable case-note log with a composer, and status-aware actions in .pg-actions. The core workflow is review, then forward to the PM (Forward to PM / Handle in region / Mark resolved), with live KPI updates.
Requests Requests from clusters and departments → a request details page to review and forward to the PM, or decline in region. The PM owns the final approve/deny.
Equipment / Contractors Read-only region roll-ups (equipment with condition filter + counts; contractor engagements across clusters). An equipment row opens the site holding the item on its Equipment tab — the same target the Facility Manager uses, so an item reads the same at both tiers. A contractor is a compact record, so its row opens a centred read-only .dlg (Close only, no action) whose Clusters field links each cluster the contractor covers into that cluster’s record — the dialog is a route, not a dead end.
Settings Profile, notifications and region preferences on the canon .settings-layout.

There is no standards library surface. The SOPs & Standards sidebar item and its list page were removed across the facilities personas. A site record’s SOPs tab still lists the standards that apply to that site, and a row still opens the read-only standard details page with its per-cluster acknowledgment rollup and the “remind cluster managers” nudge for pending ones — the page is reached from a record now instead of from a library, and its trail leads back there.

Atlas is multi-persona. The regional manager’s job — overseeing several clusters, triaging escalations, and routing to the PM — is distinct from owning the estate (PM) or running one cluster (Facility Manager). It holds no estate configuration: SOPs are read-only, and capital / cross-region calls are forwarded to the PM. This flow is the dedicated default surface for anyone with the Regional Facility Manager role. Its cluster roll-up deliberately ties into the Facility Manager persona (the Ogun cluster and its manager) so the hierarchy reads end to end.

The interactive prototype lives at ./index.html. Edit that file directly when iterating; no build step. Built to Polaris/Caesar web canon (shell · .pseg tabs · .tbl tables · .pstat KPIs · .badge b-* · case-note .log-* timeline · .settings-layout), details pages for every rich record (issues, requests, standards, clusters, sites) instead of side drawers, and boots straight to the dashboard per current canon. Lint-clean via node site/scripts/lint-canon.mjs.

Three or more filters collapse behind one button. The Facilities head carried three inline .filt-selects and now opens a .dlg from one .btn-sec with a count badge, Reset/Apply, and removable .chips. The Issues, Requests and Equipment heads keep their two inline filters — the rule is three or more.

One detail-row atom. .td-row was declared here and instantiated by nothing while diRow() emitted a bespoke .dw-row, and a third key/value grid did the same job again. Both were replaced by .td-row. All three now route through the canonical .td-row with a per-field icon; no dw- identifier remains.

The Overview carries direction. A .chart-row pairs an 8-week trend line with a by-cluster breakdown computed from ISSUES, rolling any tail past four bars into an explicit Other (n). Two KPI values carry a .trend chip, and each week has a .chart-tip hover readout.