The two screens a customer admin sees after Finish

The customer's own pre-launch checklist (#9320, #9333) and the calendar door reopened for an org admin (#9326) — photographed for the first time, as a real customer admin at an onboarded company.

18 Sept 2026 · branch lane-q-onboarding-evidence · captured against propflow-stage · at 7be50f114e

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 · Settings, as the company's own admin — the pre-launch checklist at the top of the page

This is the screen the flow map listed as unphotographable. Its known-gaps list has carried the same line since 2026-09-14: the capture tool has no identity that is both a company admin and already onboarded; the staff identity is the one role excluded. That is now false. scripts/seed-evidence-identity.ts --role=org_admin mints a real customer admin through the product's own back-office invite and sign-up routes, and pointing it at a stage company that has already been set up is what gets that admin past the wizard — shouldRouteUserToOnboarding is what used to eat every attempt.

What the admin sees first is Before Clara goes live — the customer's own copy of the checklist staff read beside the live switch (#9320), with the billing row #9333 added and the same warn-when-red rule. It is a promise, not a control: PropFlow turns Clara on once these are done.

Asserted in the captured DOM — Organization Settings · Before Clara goes live · PropFlow turns Clara on once these are done. · Connect a calendar for tours · Set up billing · Leasing email · AppFolio. The checklist heading, its promise sentence, both rows, and the Integrations block underneath — read off the page as a customer admin, not as staff.

Settings, as the company's own admin — the pre-launch checklist at the top of the page

2 · The same page on a phone

The checklist keeps its rows and its promise line at 390px, above the company fields.

Asserted in the captured DOM — Before Clara goes live · PropFlow turns Clara on once these are done.

3 · Profile — "My calendar", the door #9326 reopened for an org admin

The other half of the gap. The 2026-09-17 ruling is that the wizard never asks the company admin for a calendar — teammates are asked, the admin is not. #9326 was the reviewer's catch that the ruling, applied literally, would leave an admin who also gives tours with no way to add one at all. So the door stays open here, in Profile, and only here.

Read the block above it first, because it is the reason this card is not confusing: Clara sends, replies and books tours through your company's connections, not your own, then the company's leasing mailbox and leasing calendar, both connected and both pointing at Manage on the company page. Under them, My calendar — Not connected with its own two vendor buttons. The admin's personal calendar is an addition to the company's setup, never a substitute for it — which is exactly the mistake CompanyConnectionsStatusCard's own header records a customer making.

Asserted in the captured DOM — Clara sends, replies and books tours through your company's connections, not your own. · Manage on the company page · Leasing mailbox · Leasing calendar · My calendar · Connect Microsoft · Connect Google · Organization Admin · Runs the account — sets up the company and manages the whole team. This is a role at your company, not PropFlow platform administration.. The company-connections framing, both company rows, the personal card with both vendor buttons, and the role line that proves who is looking — an org admin, not platform staff.

4 · Profile on a phone — the company rows and the personal card stack

One column: the company's connections, then the admin's own calendar with its two buttons full width. Nothing is clipped.

Asserted in the captured DOM — My calendar · Connect Microsoft · Connect Google

How to re-run this, and why it is a separate page from the whole flow

The identity. This run signs in as a purpose-built address on @propflowai-test.local (deliberately outside the @propflowai.co staff suffix, which the auth chokepoint coerces to platform staff), role org_admin, at the stage company Fairhaven Residential (TEST). It was minted by the product's own routes — back-office invite, then sign-up, then a verified sign-in — with no table write and no fabricated session:

EVIDENCE_IDENTITY_EMAIL=<an address off the staff suffix> \
EVIDENCE_IDENTITY_PASSWORD=… \
  npx tsx scripts/seed-evidence-identity.ts --base-url=<target> \
    --org=org_53047a06-2c49-4231-92c2-6f2a7009149a --role=org_admin

npx tsx scripts/ui-evidence.ts evidence/onboarding-admin-settings.json \
  --identity=non-staff --base-url=<target>

Where the credential has to be for the run to find it. evidenceIdentityCredential() (scripts/stress-common/smoke-credentials.mjs) looks in exactly two places, in this order: the process environment (EVIDENCE_IDENTITY_EMAIL / EVIDENCE_IDENTITY_PASSWORD), then .env.local at the repo root. Nothing else is read — so export the two variables for the command, or put them in .env.local. It throws rather than defaulting, because every address the repo could default to is on the staff suffix.

This capture passed them inline on the command rather than editing .env.local, whose EVIDENCE_IDENTITY_* pair already names a different, non-admin identity that other specs use. A copy is kept outside the repo at ~/.config/propflow/evidence-orgadmin-identity (mode 600) — no code reads that path; it is a note to the next person, because seed-evidence-identity.ts is idempotent but does not RESET a password: re-run it on an address that already has one and it answers already has a password and carries on. So whoever re-captures this page needs that copy, or mints an address of their own.

The script's own header warns that a freshly minted org_admin lands on connect-pms rather than the page you wanted, and that is true of a company nobody has set up. Pointing it at a company that is already onboarded is the whole trick, and it is why these two screens went a month without a picture.

Why this is not folded into the whole-flow page. ui-evidence signs in ONCE per run — --identity is a flag on the run, and a section that tries to stage an auth cookie is refused by name (SpecStagedTheSession). The whole-flow page needs the platform-staff session for its four staff frames, so a customer-admin frame cannot share that run. Two identities, two pages, until the tool learns a per-section identity. That is a tool limit, stated rather than implied.

What is still not here. The connected state of My calendar needs a real vendor round trip, which no capture makes. The billing row's paid state needs a Stripe test key, which no environment has (the sizing page). Every address on screen belongs to a stage fixture on @example.test; the run's own contact scan is what says so.