Notification control across every account

What it is

The operator's view of the same rows a builder edits on their own Settings screen. Accounts with no saved rows are called out explicitly as 'Using defaults' rather than shown blank.

Also called: manage notifications for a client · sub-account notification settings · turn off emails for one tenant

See it

Notification control across every account

Customer	Building	Amount	Status
Sutter Kline	Equipment Storage	$15,640	Sent
Ivy Brubaker	40×64 Shop	$11,650	Paid
Gideon Alt	Barndominium	$13,360	Open
Sutter Kline	Hobby Shop	$1,960	Sent
Ivy Brubaker	40×64 Shop	$10,130	Approved

The tenant list with email/in-app counts and 'Using defaults' badges, one account expanded into its matrix. platform/settings/notifications. Sample data — no customer information appears here.

How it works

1Reads and writes go through a platform-owner-gated route, because the ordinary database proxy is locked to the caller's own account.
2Sweeps are confirmed with copy naming the account, and state what stops and what keeps working.
3Rows come from the shared event catalogue so the two screens cannot describe different things.

Why we built it

The page states the lie it refuses to tell: 'an org with no saved rows is NOT silent — notify.ts falls back to the registry defaults, so those accounts are receiving the full default set. Showing them as blank would be a lie.'

The problem

No operator view of per-account notification state
Default-configured accounts appearing silent

Sound familiar?

“a client says they're getting too many emails”“I need to fix this for them without logging in as them”“which of my accounts are actually sending”

What you get

Fix a client's notification noise in one place

Honest reporting of accounts running on defaults

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →