The availability source leaves Property Settings

A dropdown asking a customer to pick between internal adapter names becomes one line telling them their PMS is connected and how current the answer is. Nothing they hear changes.

PR #7443 · captured 2026-09-09 from a dev server on propflow-dev (anonymized by construction, ADR-0097/0110) · contact scan clean across 3 pages · 11 assertions checked in the captured DOM

BEFORE — a dropdown of adapter names, on the customer's own page

Scroll to Leasing & tours. Under it sat "Pricing & availability source" — a dropdown offering Automatic, Rent roll (PMS), Property website, and a greyed-out Manual marked Not ready yet — with two hint lines beneath: "Automatic — currently: Rent roll" and "Typing in your own list of homes isn't available yet."

Three things are wrong with putting that question to a customer. It asks them to choose between words that are ours, not theirs (Property website does not mean their website — it means a pricing vendor's portal). It is a control whose wrong setting takes their leasing offline, on the page they visit to change their office phone number. And it is a per-property choice for something that is a per-COMPANY fact: what a customer has — a PMS API connection, only a database name, a vendor code, a document their team keeps — is learned once at onboarding, not re-answered per building.

Provenance note. This capture ran against a dev server on origin/main — the commit this branch departed from, which is what a "before" means here. The capture tool prints a caution whenever a section points at the current tip of main, because after a merge that tip is the after. It is not merged; main does not contain this change.

Asserted in the captured DOM: Pricing & availability source Typing in your own list of homes isn't available yet Leasing & tours
The dropdown's own label and the second hint line asserted in the DOM on the commit this branch departed from, plus the card they sat in. Those two strings are the control's static chrome — they render before the settings values land — and they are exactly the strings the AFTER's unit assertions now demand are ABSENT.

AFTER — the dropdown is gone, and the PMS row is correctly absent

The same page on this branch. Leasing & tours is exactly as it was minus the dropdown and its two hint lines: tour duration, application link, follow-up delay. The stored leasingSource value and its API route are untouched, so Yale stays pinned to its vendor portal and Camellia stays derived to its rent roll, byte-identically — only the control is gone.

And the Integrations card still shows two rows, not three — which is the new row working, not missing. The PMS row reports a fact about the PMS connection, so it renders only for a property that has one (Property.pmsSource). This capture's property has none in the anonymized dev data, so there is nothing truthful for the row to say and it does not appear. That is the same shape as a real property answering from a pricing vendor's portal rather than a PMS, and it is the branch an earlier cut of this change got wrong: it rendered a hardcoded "AppFolio" label over whichever store happened to answer.

The row's present state — named from the property's own PMS, Connected with a relative sync time or Not synced yet, and carrying no button at all — is asserted in settings-pages-name-themselves.test.tsx against a connected payload, including the Yardi-not-AppFolio case. See the closing note.

Asserted in the captured DOM: Integrations Outlook Calendar Outlook Email Leasing & tours Tour Duration
The card and both Outlook rows, and the untouched Leasing card. The two REMOVALS this section is about — the dropdown and the PMS row's absence without a connection — are negatives, asserted in the unit suite rather than inferred from a picture that did not contain them.

The Integrations card at the fold

The card at the size a customer meets it. Each row is logo, name, one-line description, status cluster on the right — the shared IntegrationRow, not forked markup, which is what the PMS row slots into when the property has a connection. Its cluster is a badge plus a sentence rather than a badge plus a button: it is the one row that reports rather than asks.

Asserted in the captured DOM: Integrations Outlook Calendar Outlook Email
Both connection rows present in one viewport, above the fold.

What the pictures cannot show

Both halves of this change are NEGATIVES, and a screenshot of a page without a control proves only that the capture did not find it. They are asserted in settings-pages-name-themselves.test.tsx, which renders the real page and reads its text: the four removed strings (Pricing & availability source, Rent roll (PMS), Automatic — currently, Typing in your own list of homes isn't available yet) must be ABSENT, and the PMS row must be absent when pmsConnection is null. The BEFORE capture is the other half: it proves those strings were there to remove.

The row's PRESENT state is asserted the same way, against a connected payload, because the anonymized dev data this artifact is allowed to capture from has no PMS-connected non-test property: that it is named for the property's own PMS (a Yardi customer's row says Yardi, not AppFolio), that it shows Last synced from the PMS's own heartbeats, and that it carries no button at all — asserted on the ROW rather than the page, since the page has plenty.

The same file's guard moved rather than loosened. It used to demand the page did NOT contain the word AppFolio, protecting against the organization-level PMS connection card leaking onto a property page. That still stands — no credentials and no Connect/Disconnect controls are here — but a property-level sync line is a property-level fact, so the word itself is now expected wherever a connection exists.