Settings, split into its four levels
One 'Settings' page became User / Organization / Property / Admin — each names itself in the top bar and the h1, and the scope follows the property picker the way Vercel's settings follow the team or project you are in.
7 Sept 2026 · branch settings-decoupling · captured against propflow-stage · at cd913dadb1
Data note. Every name and balance below comes from propflow-stage, which is anonymized by construction (ADR-0097/0110 — phones in the impossible +1000 NPA, emails @example.test). The identical capture against prod would carry real tenants' names and balances and is not safe to attach anywhere, which is why the generator refuses to run against one.
1 · BEFORE — one page, one title, and a property nobody picked
Every setting the product has, under one word. Personal fields (Your account), the company's billing, the PMS connection and a whole run of per-property cards sat in one scroll — and with All Properties selected in the picker, the per-property group quietly edited whichever property useActivePropertyId fell back to (the test property, then the first one). Fede on the 2026-09-07 standup: "we've just mashed all the settings and threw them at the wall here." Gera: "if I click Camellia, is this now property settings? … When I'm in All, which property is it?" Look at the eyebrow above Calls in this capture: the picker says All Properties and the cards are editing a property nobody picked.
Asserted in the captured DOM — Settings · Personalization · Company Name · Outlook Calendar · Maintenance Automation. The single title, the standalone Personalization card, a company field, an integration and a per-property card — all on one page — asserted in the DOM on origin/main. The eyebrow under Integrations names the property the per-property cards silently fell back to while the picker says All Properties.
2 · Organization Settings — /settings under All Properties
The picker says All Properties, so this is the organization: who the company is, what it pays, the PMS it runs on, the whole product's follow-up cadence, and who works there. Nothing about one building. The name is in the top bar's centre — the same slot a prospect's Prospects / Raul Perez trail uses — and in the h1, from one string (SETTINGS_SCOPE_TITLE) so the two cannot disagree.
The Follow-ups card is here as well as on the property page — as the browse-and-compare list (each lane says to pick a property to edit it; editing is on Property Settings). It is here because every policy drawer's All policies → link is /settings#follow-ups whatever the picker says; the local review caught that link landing on nothing under All Properties, and this is the fix.
Asserted in the captured DOM — Organization Settings · Company Name · Billing · AppFolio · Follow-ups. The level's name, the four org-only cards, and the follow-ups landmark asserted in the DOM; no property card is on this page.
3 · Property Settings — the same URL with a property picked
Pick a property in the top-bar picker and the same route becomes that property's settings, subtitled with its name: Outlook calendar and email (keyed by propertyId today — the org-level Outlook connection is Fede's onboarding seam), the phone lines Clara dials, tours and renewals, reminders, maintenance automation, follow-ups. The page is keyed by property id, so switching the picker remounts it with fresh state — no stale form values from the previous property.
Asserted in the captured DOM — Property Settings · Camellia Apartments · Outlook Calendar · Leasing & tours · Maintenance Automation. The level's name, the picked property's name as the subtitle, and three property-only cards asserted after the picker change settled.
4 · User Settings — /settings/account
Who you are and how the app reads to you. Name, email, phone, role — and the time-zone preference as a row inside Profile rather than its own card, which the founders called out ("it shouldn't be like its own section, like the first thing that pops up"). Reached from the side-nav popover's header row, below.
Asserted in the captured DOM — User Settings · Profile · Time zone. The level's name, the one card, and the time-zone row asserted in the DOM; 'Personalization' is absent.
5 · The popover header row is the way to User Settings
The Vercel shape Gera described: click the ⋯ on the avatar row, the popover's name/email header carries a gear on the right, turns gray on hover, and is a link to /settings/account. The popover's old separate Settings row is gone — it pointed at what is now the organization's page. The rail's Settings item is the organization's or the property's; the popover's is yours.
Asserted in the captured DOM — Theme · Sign out. The menu's surviving rows asserted after the trigger click; the header row is the [data-pf-user-settings] link the actions wait for.
6 · Admin Settings — /admin/settings, and the rail agrees
"System Settings" is now Admin Settings: the fourth level, PropFlow staff controls. The rail entry, the h1 and the top-bar crumb all say the same thing (the rail used to say System Settings while the popover's Settings went somewhere else entirely). The directory moved with the name; /admin/system-settings is a redirect() stub registered in NAV_REDIRECT_STUBS so bookmarks keep working and the rail never soft-navigates a stub.
Asserted in the captured DOM — Admin Settings · Feature Modules · SMS Messaging · Vendor Quote Emails. The level's name and the unchanged toggle sections asserted in the DOM — same content, new name.
What the split deletes
The dead featureFlags fan-out (Save re-POSTed four platform-wide flags nothing on the page displayed), the This property · X eyebrow with its silent fallback to the test property, and the popover's ambiguous second Settings row. No page can render a property setting against an unnamed property any more: All Properties is the organization, a picked property is that property, and there is no third state.