design

Facilities Product Manager — flow

Atlas’s UI for the Facilities Product Manager (Super Admin) persona. This is the design a Facilities PM sees when they log into Atlas.

Live interactive prototype: /products/atlas/flows/facilities-pm/ — the canonical Facilities PM flow as a single-file HTML demo. PRD: PRD.md — engineering spec (persona, lifecycle/status model, screen specs, data model).

Persona summary


Name	Facilities Product Manager (Super Admin) · prototype persona Ciroma Chukwuma Adekunle
Audience	The single accountable owner of the physical facilities estate
Surface	Atlas (web, desktop-first 1440px)
Auth context	Internal employee SSO; Super Admin — full read/write across all facilities data + configuration
North star	Facility Health — share of facilities in a Healthy state

Primary jobs to be done

Monitor Facility Health and clear the needs-attention list
Run facility issues through Open → In Progress → Pending Approval → Resolved (with an immutable case-note log + photo/video evidence)
Decide equipment + cross-department requests, and provision approved equipment
Keep equipment inventory, condition and contractor engagements current
Decide the locations the Location Acquisition Manager submits, and move accepted projects through construction to handover

Standards are no longer a surface here

The SOPs & Standards sidebar item and its library page were removed from this flow, along with the authoring dialog behind them, as part of the same removal across the facilities personas. The Standards sidebar group went with them: an .sb-group heading over nothing is a collapsed-rail artifact, not a nav section.

SOP references stay, because other work depends on them: a site record’s SOPs tab lists the standards linked to that site, a location is still surveyed against a named requirement SOP, and an issue can still name one. What is gone is the place to author, version and publish them.

Worth stating plainly: authoring standards is still assigned to this persona in PRD.md, so the PRD and the prototype now disagree on purpose. Removing a surface does not retire a requirement — if the capability comes back it should return here, and the PRD is the record of that.

The dashboard stat row

Four .pstat cards, each linking to the surface it summarizes:

Card	Value	Links to
Facility Health	share of sites healthy — the north star	Facilities
Resolution velocity	median days from filed to resolution approved	Facility Issues
Pending Requests	submissions still `IN_REVIEW`	Requests
Projects	projects in flight, with construction and awaiting-decision counts	Projects

Open Issues and Equipment used to hold the last two slots and were dropped. Both restated a number the sidebar badge already carried, and the issue count was the one figure on this dashboard that its own dataset could not account for — it read 17 against a 12-issue array. What a PM cannot get anywhere else is how fast the estate is clearing work and where expansion stands, so those took the slots instead.

Every value except Facility Health is derived, and refreshed by each render pass. renderOverviewKpis() computes them from the same arrays the surfaces render, and the surface renderers call it, so approving a resolution moves the velocity card, approving a request moves the pending count, and accepting a location moves the projects card — without a reload. projStats() is the single definition of the project counts, read by both this row and the Projects stat row, so the two cannot disagree. The sidebar badges for issues and requests derive the same way.

Facility Health is still typed, deliberately. This flow’s facilities array holds 13 of the estate’s 39 sites, so deriving the card would report a health figure over 13 sites and contradict both the 36 of 39 it states and the VP of Facilities’ portfolio roll-up. The card cannot become honest until the dataset covers the estate it claims; that is a data decision, not a KPI edit, and it is recorded as open in the buildout spec.

Resolution velocity has no clock to read but the "x ago" strings already in each issue’s log, so agoDays() parses those rather than adding a second and disagreeing source of truth for timing. The reopened issue counts toward the median: its first resolution still took the time it took. The sub-line names the sample size, because a median over three resolutions should not be presented as though it were over three hundred.

Expansion — the PM half of the project lifecycle

The Projects surface #pg-projects is where this persona’s expansion authority lives. The Location Acquisition Manager sources candidate locations and files case reports against the PM’s requirement SOPs, but two decisions are the PM’s or the VP’s alone:

PRD	Who	Where it lives here
FR-8	PM or VP accepts a location, which becomes a Project	Awaiting your decision card → row click → the Review location `.dlg` (read the case report, then Accept, or Send back with a reason)
FR-11	PM or VP advances a project stage	Project details page `#pg-project` → `.pg-actions` → Advance to <next stage>

Both were specified against this persona and had nowhere to be performed, so the Location Acquisition Manager was read-only on a stage no surface could move. Accepting a location creates the project at Leased and deliberately leaves lease:null: filing the lease and landlord record is the Location Acquisition Manager’s job (FR-9), so this flow reads that card but never edits it.

Reading the case report before deciding

FR-8 is a judgment, and the evidence for it is the case report the Location Acquisition Manager filed against the requirement SOP (FR-6). Naming that report in a grey box is not reading it, so Review location carries a Read case report button that unfolds the report in place: the report’s own fields as canonical .td-rows (the .dw-row elsewhere in this flow is the pre-canon atom it replaces), the case notes in a read-only .readonly-box, and the photo/video evidence as a .media-grid of captioned tiles.

It unfolds inside the same .dlg rather than opening a second one over it, for two reasons: the report and the decision fields stay in one scroll, and a half-typed Note to the Location Acquisition Manager survives the read — a stacked dialog would put the note behind the thing the PM is reading in order to write it. The panel is folded away every time the dialog opens, so the surface still reads as a decision; the button hides altogether for a submission with no report attached.

caseReport carries the same fields as REPORTS in the Location Acquisition Manager flow (title · status · notes · media), so one report reads identically to whoever opens it. Captions are held to one line — a 72px tile fits about 13 characters, and a caption that wraps covers half the thumbnail it labels — with the full filename on the tile’s title.

STAGES and PROJECTS are copied verbatim from the Location Acquisition Manager flow, and the stage history uses the same canonical .tl-step-* timeline (DESIGN.md “Status timeline”), so one project reads identically to both personas. Stages are Approved → Leased → Design → Construction → Handover — an Approved entry state (grey; where accepting a candidate now mints the project, lease not yet filed) prepended to the PRD’s FR-10 four, which keep the 3+1 colour rule: Leased amber, Design and Construction blue, Handover green, a slipped handover red.

Both tables here are deliberately narrow. The decision queue has no Filed by column (it is always the Location Acquisition Manager, which the card head states) and no in-cell buttons, and the projects table has no Region column (the sub-line carries it and search matches on it). Each was cut after measuring real horizontal overflow at 1440.

Acquisition clusters — opened here, scouted downstream. The Projects head carries a New cluster action (#dlg-cluster): the PM opens a scouting cluster — a named zone with a coverage area and a target facility type — into the Acquisition clusters card that sits above the decision queue, and a cluster row opens its read-only record (#dlg-cluster-view). This is the upstream of the pipeline: the Location Acquisition Manager files locations within the clusters the PM (or VP) has opened, so the scout’s File location cluster picker is generated from the same CLUSTERS list seeded here — one cluster reads the same at every tier, the direction running PM/VP → scout. Seeded with Lagos and Ogun; opening a cluster appends to the list and toasts that the scout can now scout in it. Staffing a cluster: the cluster record carries an Assign people action (#dlg-assign) — the PM (or VP) assigns the cluster’s Location scout (who sources within it) and its Cluster facility manager (who runs its live sites) from a shared roster; either may be Unassigned. Both read out as columns in the Acquisition clusters card.

Why this flow exists separately

Atlas is multi-persona. The Facilities PM’s job — the physical estate, its issues, equipment, contractors and standards — is distinct from onboarding, swap ops, inventory or telemetry. This flow is the dedicated default surface for anyone with the Facilities PM (Super Admin) role. Four interacting personas (Facility Manager, Station Manager, Location Acquisition Manager, Department Requester) are planned companion flows (see the PRD §12).

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-* · centered .dlg · details pages for rich records, never a side drawer), lint-clean via node site/scripts/lint-canon.mjs.