Platform console (/hq)
The console is where Complied's own staff (platform operators) look across every tenant on the platform: which firms there are, who signs in, what was done, and whether the city's public data is flowing. It is not a tenant's workspace and has no tenant's branding. Doing a tenant's work happens inside that tenant's own app, reached with View as.
Only a platform operator opens it. A tenant's staff (even its admin) and client portal logins never see it in their navigation, and the address sends them back to their own home page. The database refuses everything the console reads or writes to anyone else, whatever the screen shows.
Signing in
An operator signs in on the ordinary login page and lands on the console. An operator account has
no tenant of its own; it is a platform_operators row, provisioned by hand (never self-service).
Operator accounts should use two-factor authentication (security).
The pages
| Tab | What it shows |
|---|---|
| Overview | Tenants, active users (staff and portal), buildings tracked and projects open across the platform; a tile per page; the tenants with the most overdue lead orders; recent audited activity; feed health; any View as session running now |
| Tenants | Every firm, with its staff and portal logins, clients, buildings, open projects, overdue lead orders and when anything was last audited for it. Search, filter active or inactive, and sort |
| Tenant (open one) | Its status, slug, branding and numbers, then tabs: Buildings (by client, with open and overdue lead orders), Staff & roles (each person's role, status and last sign-in, and the tenant's roles with their key counts), Portal logins (by client), Activity (its audit log) and View as history |
| Users | Every login on the platform: staff, portal logins and operators. Search by name, email, tenant or client; filter by type, tenant and status; see each one's last sign-in |
| Buildings | Every building any tenant tracks, worst first by overdue lead orders, with its tenant and client |
| Audit log | The append-only audit log across tenants, grouped by day. Filter by tenant, action, person and period (?action=impersonation shows View as sessions) |
| Data feeds | Each NYC Open Data feed's last run, rows loaded, failures in 7 days and backfill state; failed and partial runs in 30 days; the records that matched no building; recent runs |
| Storage | The database's size and biggest tables, and file storage by bucket and by tenant |
Every figure is read live. Where the client's design showed plans, revenue, vendors or API call statistics, the console leaves them out until there is real data behind them (GitHub Issues).
Turning a login on or off
On a tenant's Staff & roles or Portal logins tab, or on Users, Turn off / Turn
on changes whether a staff login or a client portal login may sign in. A reason is required.
The change and the reason are written to that tenant's audit log, where its admin can read them
(operator.staff_deactivated, operator.portal_login_activated and so on). A tenant's last
active admin can't be turned off: the database keeps one. Operator accounts aren't changed here.
View as a tenant
View as (on the Tenants list and a tenant's page) opens that tenant's staff app exactly as its admin sees it, with every permission:
- Give a reason (required) and how long it should last (15 minutes to 8 hours).
- The app opens on the tenant's My day. A strip across the top of every page says Viewing as
· reason · ends with Stop. - Stop ends the session and returns to that tenant's console page. The session also ends on its own when its time runs out; the app notices and goes back to the console.
While viewing as a tenant you see only that tenant's data, as its own staff would. The console
itself stays closed until you stop (opening /hq offers to stop for you), because it needs to
read every tenant at once.
Every start and stop is audited with the reason, and the tenant can read it (its Activity, and its own audit log in the app). A tenant's page lists every session into it under View as history: who, why, when it started and how it ended.
How the database enforces all of this is in permissions.