Notifications and email diagnosis

Purpose, scope, and required role

Use this page to diagnose a report that a notification, push, invitation, or email did not arrive—or arrived unexpectedly. It is read-only unless the requester separately authorizes a specific outgoing message, recipient, and text. Authorized technical staff may inspect the minimum records necessary.

Diagnostic path

1. Capture the type (in-app, push, invitation, or email), related route/record, and time window. Do not collect passwords, message bodies, or tokens.
2. Open the user’s in-app notification center and check the unread count and visible notification state. An empty center does not establish provider non-delivery.
3. Check Organizer Alert Settings for the configured behavior. Ask Engineering to trace the application handoff and provider webhook when the issue crosses into email or push delivery; source configuration is not delivery evidence.
4. Under approved access, correlate the specific record with authorized audit/delivery data. Describe observed queued, accepted, bounced, or webhook state exactly; leave unknown as unknown.
5. Report configured behavior, application evidence, provider evidence if observed, and remaining gaps separately.

Failure, recovery, and escalation

Do not test by sending a new message. A missing webhook, delayed push, or absent provider record requires Engineering/provider escalation with timestamps and sanitized IDs. Unexpected recipients, delivery to the wrong person, bounced addresses, or suspected forged webhooks are incidents. Never copy message bodies, addresses, provider tokens, or webhook signatures into this handbook. For a person unable to see their own notification, use access troubleshooting.