Super-admin

You run the platform. You're read-only on every brokerage's day-to-day data. Your write surface is brokerages, landlords, users, and rent guidelines.

Last updated: 2026-05-10

You're the platform operator — Dor today, eventually Anthropic-side support staff. Your job is to keep the platform running, onboard new brokerages, manage the global rent-guidelines table, and step into customer-support situations when a brokerage needs help.

Where you land

Your home page is /admin. Not /dashboard — that route auto-redirects you. The admin page shows the platform overview:

• Growth row: brokerages, users, landlords, buildings, units, each with a 30-day delta
• Role breakdown: how many admins, agents, photographers, landlord members across the platform
• Stuck-onboarding list: brokerages that started the wizard but haven't finished
• 7-day active-brokerage leaderboard
• Platform-shape audit feed (across all brokerages)
• System health: notification volume, cron heartbeat
• 30-day compliance signal: rent overrides, GCE flips, regulation changes

Below that, the admin tools tile grid links into:

• /admin/audit — every audit row across the platform, filterable
• /admin/rent-guidelines — RGB orders and HCR caps
• /data-quality — the gap report (units missing rent, leases missing end dates, etc.)
• /admin/brokerages — the brokerage directory

What you can edit

You write on brokerages, brokerage members, users, landlords, landlord members, and rent guidelines. That's it.

You can't:

• Record a lease on any unit
• Move a unit's status
• Override a rent cap (that's a brokerage admin)
• Flip a unit's Good Cause Eviction coverage (also brokerage admin)
• Edit any building or unit field

One narrow exception on the outbound side: you can send landlord-facing renewal pricing PDFs and comp reports. These are notification dispatches, not unit-data writes — they read the data the brokerage has already entered, render it, and email it. The audit log records the send under your actor id so attribution stays truthful.

This isn't "the access layer is being annoying." It's load-bearing. The audit log's value depends on actor attribution being trustworthy. If super-admin could write on a brokerage's data, then every audit question — "who set the rent on unit X?" — has the answer "could have been platform support" and the trail loses meaning.

If a brokerage hits a bug that only a write can fix, the workflow is: diagnose in support mode (below), tell the brokerage admin exactly what to do, and watch them do it. The fix is theirs.

View as <brokerage>: customer-support mode

In the sidebar footer (or the mobile drawer footer), you have a View as <brokerage> picker. Pick a brokerage:

1. A sticky amber banner appears at the top of every page so you don't forget you're scoped in
2. The sidebar grows to look like a brokerage admin's — Inventory, Buildings, Deals, Tenants, Lease expiry, Team, Analytics all show up
3. Operational pages narrow their queries to that brokerage's slice

This is chrome only. Reads narrow; writes still return false. You can navigate /inventory, click into /units/[id], see exactly what the brokerage admin sees. Try to click "Override rent" and you'll get the same "not authorized" response as you would without scope.

The scope is a signed cookie with a 4-hour TTL. Tampering with it doesn't work — the signature won't match.

Exiting support mode

Two ways:

• Click "Exit support mode" at the top of the View-as picker dropdown
• Click the pill on the amber banner

Either way, you snap back to the platform admin view and the picker shows nothing selected.

Workflows

Onboarding a new brokerage

Brokerages self-serve through /onboard/new-brokerage — the first user becomes the owner, signs in, and is off and running. You don't have to do anything to provision them.

Where you come in:

• The owner can't sign up because of an email conflict — fix on /admin/brokerages
• Someone tries to start a second brokerage and the partial unique index blocks them — confirm whether it's a mistake or a real second-brokerage scenario
• Welcome emails aren't landing — check /admin/audit for the invite verb and the system-health card on the platform overview

Maintaining rent guidelines

Open /admin/rent-guidelines. This is the global table of:

• RGB orders (one-year and two-year guideline percentages, vacancy allowances, longevity caps) — published annually
• HCR Maximum Collectible Rent caps (rent-controlled) — published annually

Each row has effective_from / effective_to. When a new RGB order drops every June, add a row with the right effective range. The rent cap check uses the row that's currently in effect for any unit it prices.

This table is global because the regulations are global. Brokerages don't write here.

Reading the audit log

/admin/audit is your truth source. Filter by:

• Action (verb — "unit.status_change", "lease.record", "rent_override", etc.)
• Entity (the subject — a specific unit, building, deal)
• Actor (which user did it)
• Date range

You can CSV-export up to 10,000 rows. The audit log is append-only, which means corrections are NEW audit rows pointing at the fix, not edits of the original. If something looks wrong in the log, look up the verb, the actor, and the timestamp — the action was real, and the log doesn't lie.

Compliance signals

The 30-day compliance signal on /admin flags:

• Rent overrides — brokerage admins pushing rents past the legal cap. Each override carries a justification. Spot-check periodically.
• GCE flips — unit Good Cause Eviction coverage being changed. Mostly legitimate (e.g. a new tenant pushes rent above the high-rent exemption threshold) but worth a glance.
• Regulation changes — units re-classified from stabilized to free-market, etc. Should be rare.

None of these are alarms — they're context. If you see a spike from one brokerage, that's a conversation to have, not an automated action the system takes.

Things to remember

• Your /settings shows only the Personal section. You don't have a brokerage to configure.
• The sidebar is intentionally short. Your operational surfaces live under /admin/* — that's the whole platform layer.
• The "View as" cookie expires after 4 hours. If you've been doing support work and the banner disappears mid-session, pick the brokerage again.
• Don't push fixes by editing the database directly. Every fix that doesn't go through the app skips the audit log, which is the one thing future contributors trust. Use the app, or coach the brokerage admin through the app.