Most notification failures in 2026 are not broken automation. They are a delivery setting nobody checked. Work the chain in this order before opening Flow Builder.
- Confirm the Deliverability access level
In Setup, Quick Find for Deliverability. Production should read All email. If it reads System email only, every configured alert is being thrown away and nothing on the record says so.
- Verify the sending domain
Check that the domain behind your organization-wide address has an active DKIM key or a row in Authorized Email Domains. Without one, Salesforce discards the send instead of bouncing it back.
- Build the Email Alert
Quick Find for Email Alerts, click New Email Alert, choose the object, pick a template, set Recipient Type, and select the verified organization-wide address as the From. Note the API name.
- Call it from a record-triggered flow
Add an Action element, search for the alert by name, and pass the triggering record's Id into SObjectRowId. Entry criteria on the flow decide when it fires; the alert has no conditions.
- Send one real test, then read the Email Log
Request an Email Log for the window you tested in. It reports whether Salesforce accepted the message and what the receiving server answered, which a flow debug log never will.
No access, System email only, or All email. The org-wide gate on everything except the platform's own system mail.
Running user, default workflow user, or a verified organization-wide address. Only the last gives a domain you control.
Owner, owner's manager, role, public group or related contact, plus up to five hard-typed addresses.
- Every member of a public group counts separately against the daily workflow email allocation, so one alert to a 40-person group costs 40 sends.
- Workflow rules, approval processes, flows and the REST API all spend the same daily allocation, so one chatty flow can starve every other notification.
- Verifying an email address is not the same as verifying its domain. Spring '26 requires both.