design

Facility Manager — flow

Atlas’s UI for the Facility Manager (Ogun cluster) persona. This is the design a cluster admin sees when they log into Atlas Facilities. The cluster sits below the Regional Facility Manager (several clusters) and the Facilities PM (whole estate) — see the PM PRD §12.

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

Persona summary


Name	Facility Manager (Ogun cluster) · prototype persona Bukola Sanni
Audience	The cluster admin who runs five Ogun facilities day to day
Surface	Atlas (web, desktop-first 1440px)
Auth context	Internal employee SSO; cluster-scoped — triages and forwards, no estate-level config; SOPs read-only
North star	Cluster health — share of the cluster’s five sites in a Healthy state

Primary jobs to be done

Monitor cluster health and clear the needs-attention sites
Open any site’s Record (health check + Personnel / Equipment / Contractors / Issues / SOPs)
Triage an issue raised at a site: assign a contractor, or forward it to the PM
Review a request from a site or another department and forward it to the PM, or decline it
Keep equipment condition, the contractor roster and SOP acknowledgment in view

Surfaces

Sidebar surface	What it does
Overview (`#pg-overview`)	Cluster health + open issues / pending requests / out-of-service equipment KPIs, a Facilities needing attention table with a data-built reason filter, and a cluster activity feed. Every KPI is derived from the datasets behind the surface it links to, so a headline number cannot contradict the queue it points at.
Facilities (`#pg-facilities`)	The cluster’s five sites, filterable by health + type and searchable, → a per-site Record (`#pg-record`): a health check on the Overview tab plus Personnel / Equipment / Contractors / Issues / SOPs sub-tabs, each rendered for the site you opened.
Facility Issues (`#pg-issues`)	The cluster issue queue with `.filt-select` status/site filters and search in the `.tbl-card-head`, opening an issue details page (`#pg-issue`: `.pg-back` + `.pg-title-row` + `.rec-grid`): status + severity, icon key-value details, an append-only case-note log with a composer, and status-aware actions in `.pg-actions`. The cluster workflow is assign a contractor or forward to the PM (Assign contractor / Forward to PM / Mark resolved), with live KPI updates.
Requests (`#pg-requests`)	Requests from the cluster’s sites and from other departments filing in as a Department Requester → a request details page (`#pg-request`) to review and forward to the PM, or decline at cluster. The PM owns the final approve/deny.
Equipment (`#pg-equipment`)	The cluster’s 18 items with a condition filter, site filter and derived condition counts. A row opens the site holding the item, landing on its Equipment tab.
Contractors (`#pg-contractors`)	The cluster contractor roster — trade, sites covered, contact and engagement state. A contractor is a compact record, so a row opens a centred `.dlg` rather than a details page, and each site inside it links on into that site’s record.
Settings (`#pg-settings`)	Profile, notifications and cluster 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. Standards are still here, but only where a site puts them in context: a site record’s SOPs tab lists the standards that apply to it with their acknowledgment state, and a row opens the same read-only standard details page (#pg-standard) it always did, carrying the per-site acknowledgment rollup and the one write action, acknowledge for the cluster. That page’s trail now leads back to the record rather than to a library that no longer exists. A standard still applies to a site only when its type matches, so a Workshop is never asked to acknowledge a charge-bay procedure.

Notifications live on #pg-notifications, reached from the topbar bell.

What this tier can and cannot do

The cluster is the origin tier for facilities-internal issues: sites report in here, and this is where triage happens. It deliberately holds no approval authority.

Can assign a contractor, forward an issue or request to the PM, decline a request at cluster level, mark an issue resolved, and acknowledge a standard.
Cannot approve spend, create or edit a standard, or configure anything at estate level. Those are the PM’s, on facilities-pm.

A Station Manager in another department files into facilities as a Department Requester, which is why Requests carries cross-department origins alongside the cluster’s own sites.

Design notes

One dataset per concern. FACILITIES, ISSUES, REQUESTS, EQUIPMENT, CONTRACTORS and SOPS each back their own surface, the matching Facility Record tab, and the Overview roll-up. Records that also exist in facilities-regional-manager keep that flow’s ids and copy verbatim (ISS-301/302/304/309, REQ-401/404, SOP-01…SOP-07) so one issue reads identically at cluster and region tier.

Health is derived, never stored. A site’s Healthy / Needs-attention badge and its attention reason both come from its three checks — open high-severity issue, out-of-service equipment, stale condition report — read from the same ISSUES and EQUIPMENT data the surfaces show. A stored health flag drifts the moment an issue is resolved; resolving one here flips the badge, the reason filter, the directory count, the KPIs and the sidebar badge together.

Canonical components only. Record sub-panels are .rec-panel; the record’s field rows are the canonical icon key-value .td-row / .td-k / .td-ic / .td-v (this flow’s private .facts grid was removed, and no .dw-row is instantiated anywhere in the file). Case-note timelines are .log-*, the note composer wraps its textarea in the canon .fld block, and every table cell holds one line — nowrap + ellipsis is the guard, and the five-column tables add a <colgroup> that takes width from their narrow badge and numeric columns so real content fits without truncating. Measured at 1440: no cell wraps, none truncates, no table overflows its .tscroll.

Every row is a target, and no control is decorative. Each table row opens something — a site, an issue, a request, a standard, or the contractor dialog. The hardcoded prev/next pagers were removed rather than left inert: every surface fits on one page, so the .tbl-foot carries only its derived count. Each filter and search box actually filters, and the attention-reason options are built from the data so an option that cannot match is never offered. flow-probe.js passes on all seven views at 1440, and the flow sits at a zero canon baseline.

Why this flow exists separately

Atlas is multi-persona. Running one cluster — triaging what sites report, assigning contractors, and routing the rest to the PM — is distinct from overseeing several clusters (Regional Facility Manager) or owning the estate (PM). This flow is the dedicated default surface for anyone with the Facility Manager role, and it closes the bottom of the facilities hierarchy: the Regional Manager’s cluster roll-up points at this cluster and its manager, so the chain reads end to end.

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-* · case-note .log-* timeline · .settings-layout), details pages for every rich record (issues, requests, standards, sites) instead of side drawers, and boots straight to the dashboard per current canon. Lint-clean via node site/scripts/lint-canon.mjs.