Skip to main content

Lead Alert Recipients — Expected Output Spec

§0 Why​

When a lead lands, server/notifications.ts fans out to the recipients in local_business_setup_profiles.notification_preferences — primary notification_email, comma-separated notification_email_cc watchers, optional SMS (notify_sms, notification_phone, sms_urgent_only). The Becketts' current recipients (Sheri + the founder) were set by hand at provisioning; the founder asked (2026-09-03) whether this is configurable in the dashboard. It is not — this card makes it so. The engine is untouched.

§1 Expected output​

On /realtor/app/settings/notifications, ABOVE the existing per-event CRM prefs screen, a card titled "Lead alerts — who gets notified":

  • Primary email (single input, validated) + Email on/off toggle.
  • Additional recipients (chips/list; add + remove; each validated; stored as the comma-separated notification_email_cc, cleaned exactly the way notification-cc.ts parses it — same dedupe, same primary-exclusion).
  • SMS: on/off toggle, phone input (E.164-normalizable), "urgent leads only" checkbox (maps to sms_urgent_only).
  • Save writes ONLY notification_preferences via upsertSetupProfile (mutations.ts) — never any other profile field; re-read after save shows the persisted state (no optimistic lie).
  • Capability: same context/gating pattern as the sibling /api/real-estate/crm/notifications/prefs route; ?account_id= REQUIRED.

§2 Acceptance checks​

  1. Adding a CC and saving → the row's notification_preferences carries it, and notification-cc.ts parsing returns it (unit test).
  2. Removing all CCs saves an empty value the engine treats as none.
  3. Invalid email/phone rejected inline with a message; save blocked.
  4. Toggling SMS off never clears the stored phone (turning it back on remembers the number).
  5. No other setup-profile field is modified by a save (assert in test via mutation input shape).
  6. A member without the capability gets a read-only card or denial — API enforced, not just UI.

§3 Out of scope​

Per-recipient granularity (which EVENTS each recipient gets — that is the CRM prefs system below the card); push; digest routing; church admin parity.