No native browser dialogs in settings

Destructive settings actions use branded confirm dialogs and branded selects and toasts rather than the browser's own prompts.

What it is

A house rule applied across the settings tabs: the confirm step for resetting a role, deleting a preset, removing a saved signature or finalizing an invitation is a themed dialog that states the consequence in a sentence; selects are the branded component; feedback is a themed toast rather than an alert.

Also called: ugly popup · confirm box · branded dialogs

See it
No native browser dialogs in settings
Day rate
$400
Days figured
13
Crew size
3
Fuel & equipment
$300
Finished 2 days early — $1,600 back to the crew
The branded Reset confirm dialog over the presets list, with its explanatory sentence and busy state. Sample data — no customer information appears here.
How it works
  1. 1A caller stages an action and the confirm dialog runs it on confirmation, with a busy state while it works.
  2. 2Lead Access, permission presets and pending invitations all use the branded Select and ConfirmDialog components rather than native controls.
Why we built it

The Lead Access tab states it as a hard project rule — 'Brand tokens only — branded Select + branded toggle-chips, no native controls'. Beyond appearance, a native confirm can only show one line of text; the branded dialog can explain what the action will actually do, which is what makes a destructive setting safe to offer.

The problem
  • Native confirms could not explain the consequence of a destructive setting.
  • Native controls broke the product's appearance and theming.
Sound familiar?
What you get
Every destructive action explains itself before it runs.
Settings look and behave consistently in light and dark themes.

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 →