design
VP of Facilities — flow
Section titled “VP of Facilities — flow”Atlas’s UI for the VP of Facilities persona. This is what an executive sees when they log into Atlas Facilities: the whole estate, read-only. It sits above the Facilities PM (owns the estate and decides), the Regional Facility Manager (a region) and the Facility Manager (a cluster).
Live interactive prototype: /products/atlas/flows/facilities-vp/ — the canonical VP of Facilities flow as a single-file HTML demo.
Persona summary
Section titled “Persona summary”| Name | VP of Facilities · prototype persona Adaeze Nwosu |
| Audience | The executive accountable for all 39 sites across 4 regions |
| Surface | Atlas (web, desktop-first 1440px) |
| Auth context | Internal employee SSO; estate-wide but read-only — no assignment, approval or stage advancement |
| North star | Portfolio Facility Health — the share of the estate’s sites in a Healthy state |
Primary jobs to be done
Section titled “Primary jobs to be done”- Watch portfolio Facility Health and see which regions are pulling it down
- Drill from a region into its clusters and its sites needing attention
- Scan the whole estate by region, facility type and health
- Track open issues and SLA breaches across every region
- Monitor the expansion pipeline the Location Acquisition Manager sources and the PM decides
- Pull the standing executive reports
Surfaces
Section titled “Surfaces”| Sidebar surface | What it does |
|---|---|
Overview (#pg-overview) |
Portfolio KPIs, a Regions preview sorted by sites needing attention with a View all link, and an estate activity feed. A row opens the region. |
Regions (#pg-regions) |
All four regions with clusters, sites, health, needs-attention, open issues and trend, re-sortable by any of them. A row opens the region details page (#pg-region: .pg-back + .pstat-row + .pseg ⇄ .rec-panel) — clusters, sites needing attention, and regional activity. |
Facilities (#pg-facilities) |
Every site in the estate, filterable by region, facility type and health, and searchable. A row opens that site’s read-only record. |
Issues & SLAs (#pg-issues) |
Every open issue with its severity and SLA state (breached / at risk / within SLA) — the executive lens the cluster and region tiers do not carry. Filterable by region, severity and SLA state. |
Expansion (#pg-expansion) |
Acquisition clusters — the scouting zones this VP opens for the Location Acquisition Manager, created via the New cluster dialog (#dlg-cluster) — sit above the project pipeline, Leased through Handover, with slipped handovers flagged. Each cluster shows its assigned Scout and Cluster facility manager (or an Unassigned badge); a cluster row opens its record (#dlg-cluster-view), whose Assign people action (#dlg-assign) sets both from a roster. A project row opens the project read-only. |
Reports (#pg-reports) |
The standing executive reports, their cadence and when each was last generated. |
Settings (#pg-settings) |
Profile, notifications and preferences on the canon .settings-layout. |
Notifications live on #pg-notifications, reached from the topbar bell.
Read-only is enforced structurally, not by convention
Section titled “Read-only is enforced structurally, not by convention”The PRD’s FR-11 names the VP alongside the PM as a role that may advance a project stage. This flow deliberately does not: advancement stays PM-only, on facilities-pm’s project details page. The guarantee is structural rather than a note in a doc —
- No record dialog carries an action. A site, a cluster, an issue and a project all open a centred
.dlgwhose footer holds Close and a line naming who does act (“Stages are advanced by the Facilities PM”, “Assigned and resolved by the cluster manager”). There is no primary button anywhere in them. - No advance, assign, approve or resolve function exists in the file. There is nothing to call.
- Every surface’s
.pg-actionsholds Export only — with one deliberate exception, the acquisition-cluster planning on Expansion: New cluster (#dlg-cluster) opens a scouting zone, and a cluster’s Assign people action (#dlg-assign) staffs it with a Location scout and a Cluster facility manager. Both hand work down to the field; neither advances a project stage, approves a location, nor resolves an issue — the estate-decision authority that stays with the PM — so the monitor-only guarantee over the estate’s decisions is intact. (The acquisition-cluster opener isopenAcqCluster, deliberately distinct from this flow’s pre-existingopenClusterregion-drilldown — see the code comment; the two must not collide.)
A row being clickable is not an exception to this. A click routes to a read-only view; it grants no authority, which is why enabling it did not weaken the monitor-only decision.
Design notes
Section titled “Design notes”One SITES list, and everything derives from it. All 39 sites live in one array. Portfolio health, per-region health, per-cluster health, needs-attention counts, open-issue counts, the cluster and site tables on a region details page, every KPI and the three sidebar badges are computed from it. Nothing stores a count.
The sidebar badges were the exception until they were caught: typed into the markup, the Issues & SLAs badge read 7 while ISSUES held 8 — a number the KPI and the table foot both reported correctly, so the only wrong figure was the one a reader sees before opening anything. renderSbCounts() now derives all three, which is why the claim above can be made without a caveat.
This was not cosmetic. The hand-written figures had already drifted: South-East’s two clusters both read 88% when their own site counts give 75% and 100% — 88% is the region average, copied down a level. Deriving fixed it and makes the same class of error impossible next time. Resolving a site now moves its cluster, its region, the portfolio KPI and the needs-attention filter together.
Sites that exist in a sibling flow keep that flow’s name and copy verbatim. The Ogun five are facilities-manager’s, the Ikeja and Lekki sites are facilities-regional-manager’s, and ISS-301 / ISS-302 keep their ids and titles, so one site and one issue read identically at every tier. Aligning this corrected a real contradiction: the estate previously placed “Sango Retrofit Station” in the Ikeja cluster while facilities-manager had Sango as a Charge-Swap Station in Ogun, and had Ogun’s second needs-attention site as Ijoko.
Canonical components only. The read-only dialogs use the canonical icon key-value .td-row / .td-k / .td-ic / .td-v, whose CSS was already in this file and never instantiated; no .dw-row exists here. .log-note is copied verbatim from the sibling facilities flows. Every table cell holds one line — nowrap + ellipsis is the guard, and each table declares a <colgroup> sized against its longest real value. Empty states follow this flow’s own idiom: a colspan row inside the tbody, each with its .empty-ic.
Every control does something. The hardcoded prev/next pagers were removed rather than left inert — no surface paginates, so the .tbl-foot carries only its derived count. Every filter and search box filters, and the region and type options are built from the data so an option that cannot match is never offered. flow-probe.js passes on all six views at 1440.
Three or more filters collapse behind one button. Facilities and Issues & SLAs each carried three inline .filt-selects in the table head; both now open a .dlg from a single .btn-sec with a count badge, Reset and Apply in the .dlg-foot, and the active filters read back as removable .chips. The selects keep their ids inside the dialog, so renderFacilities() and renderIssues() are unchanged.
The Overview carries direction, not just levels. A .chart-row pairs an 8-week trend line with a by-cluster breakdown, and two KPI values carry a .trend chip. The breakdown is computed from ISSUES joined to SITES (an issue names its site, not its cluster) and rolls any tail beyond four bars into an explicit Other (n), so the bars always sum to the issue count. The 8-week series and the two KPI deltas are declared data — this flow has no history to derive them from. Each point has a transparent hover band carrying the canonical .chart-tip readout.
Why this flow exists separately
Section titled “Why this flow exists separately”Atlas is multi-persona. Watching an estate is a different job from running one: the PM decides and owns, the regional manager clears escalations, the cluster manager triages what sites report. The VP needs altitude and an SLA lens, and needs to be structurally unable to reach in and act — which is what makes this a separate surface rather than a filter on the PM’s.
Source
Section titled “Source”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-* · .settings-layout), a details page for the region record and centred .dlgs for the compact ones, and boots straight to the dashboard per current canon. Lint-clean via node site/scripts/lint-canon.mjs.
See also
Section titled “See also”- Atlas global DESIGN.md: ../../DESIGN.md
- All Atlas personas / flows: ../README.md
- The PM who owns the estate and decides: ../facilities-pm/design.md · PRD.md
- The region tier: ../facilities-regional-manager/design.md
- The cluster tier: ../facilities-manager/design.md