Flow Email And Notifications

Flow Email and Notifications

Use this skill when a Salesforce Flow needs to deliver a message — email, in-app notification, SMS, or Slack — to users or external addresses. Covers the Send Email action, Send Custom Notification action, SMS via Digital Engagement, and Slack via the Salesforce for Slack integration. NOT for creating or managing email templates in Setup (use admin/email-templates-and-alerts), and NOT for Email Alert workflow actions.

Three design mistakes this skill catches: (1) using Send Email when a Custom Notification would be faster and more actionable for internal users, (2) confusing Flow's Send Email with Email Alerts (different template sources!), (3) designing bulk notifications without respecting the 1,000/hour cap.

Before Starting

Check for salesforce-context.md in the project root. If present, read it first.

Gather if not available:

• Notification channel: Does the requirement need email, the in-app bell icon, a mobile push, SMS, or Slack? Each uses a different action and has different licensing.
• Recipient type: Is the recipient a Salesforce User (requires 15 or 18-char User ID for custom notifications), or an arbitrary email address (plain string for Send Email)?
• Add-on licenses: SMS requires Digital Engagement / Messaging. Slack requires the Salesforce for Slack integration configured in the org.
• Email content source: Flow's Send Email action uses a plain text body or a Flow Text Template resource — it does NOT use Classic Email Templates from Setup. That distinction is a frequent source of confusion.
• Volume: Custom Notifications are rate-limited at 1,000 per hour per org. Email sends count against the org's daily email limit (1,000 mass emails/day for standard orgs).

Core Concepts

Three distinctions cause most of the failures here. Send Email ignores the Classic Email Templates sitting in Setup — point it at a Flow Text Template resource instead. Email Alerts do read those Classic templates, but an Email Alert is a separate action inherited from Workflow Rules, and reaching for one when you meant the other is an easy slip. And recipientIds on a Custom Notification takes User IDs and nothing else: put an email address or a Contact ID there and it fails.

references/well-architected.md carries the fuller comparison, the prerequisites, and the architectural tradeoffs.

Common Patterns

Pattern 1: In-App Bell Notification on Record Change

When to use: A record-triggered or autolaunched Flow needs to alert a specific Salesforce user immediately (e.g., escalation to owner, approval request follow-up).

Prerequisite — a Custom Notification Type must exist first. Build it in Setup, or deploy the metadata:

<!-- Path: force-app/main/default/notificationtypes/
     File: Case_Escalation_Alert.notiftype-meta.xml
     desktop and mobile are the delivery channels; leaving slack false keeps
     this notification inside Salesforce. -->
<?xml version="1.0" encoding="UTF-8"?>
<CustomNotificationType xmlns="http://soap.sforce.com/2006/04/metadata">
    <customNotifTypeName>Case_Escalation_Alert</customNotifTypeName>
    <desktop>true</desktop>
    <masterLabel>Case Escalation Alert</masterLabel>
    <mobile>true</mobile>
    <slack>false</slack>
</CustomNotificationType>

What to put in each Send Custom Notification input:

Why not email: Bell notifications are synchronous with the transaction, appear immediately in the app, and do not require an email address. Email adds latency and inbox noise for internal user alerts.

Walked through end to end in references/examples.md, Example 1.

Pattern 2: Confirmation Email to External Contact

When to use: A Flow needs to email a non-Salesforce user (customer, partner, applicant) with dynamic content after a record creation or form submission.

What to put in each Send Email input:

Wire a fault connector every time. SendEmailException is what you get when a limit is breached or the address is malformed.

Why not an Email Alert: an Email Alert binds its template at design time in Setup. Send Email lets both the recipient and the body vary at run time, which is the whole point here.

Walked through end to end in references/examples.md, Example 2.

Pattern 3: Bulk Internal Alert With Rate-Limit Awareness

When to use: Record-triggered Flow needs to notify many users during a bulk save (e.g., data-load alert to 200 case owners).

Structure:

1. Compute the User ID collection in advance.
2. Check the collection size; if > hourly limit threshold, aggregate to a digest (single notification to a manager role rather than per-user).
3. For approved bulk sends, fire Send Custom Notification with the collection.
4. Track hourly volume via a custom Notification_Log__c object so the next bulk run can back off if near cap.

Why not unbounded: 200 record load with per-record notification × 5 cascading automations = bell-cap exhaustion quickly.

Pattern 4: Slack Channel Post for Cross-Team Awareness

When to use: Internal teams not on Salesforce (dev, finance, security) need awareness of a Salesforce event.

Structure: Flow uses Post Message to Slack with a pre-provisioned channel. Message contains a link back to the record (includes the recordUrl merge pattern).

Decision Guidance

Recommended Workflow

1. Confirm the channel and license: Determine which notification channel the requirement calls for and verify the org has the required add-ons (Digital Engagement for SMS, Salesforce for Slack for Slack). Do not proceed with unavailable actions.
2. Identify recipient wiring: For Send Custom Notification, locate the User ID source on the triggering record. For Send Email, locate the email address field. Confirm whether a collection or single value is needed.
3. Create prerequisite metadata: For custom notifications, create the Custom Notification Type in Setup before building the Flow action. For Slack, confirm the workspace connection is active.
4. Configure the action: Add the appropriate action element (Send Email, Send Custom Notification, Send SMS, Post Message to Slack). Map all required inputs. For email, set Subject, Body (Text Template), and To address. For notifications, set recipientIds (collection), title, body, and optionally targetId.
5. Add a fault connector: Every notification action can fail. Wire a fault connector to capture $Flow.FaultMessage, log or notify an admin, and avoid silent failures.
6. Test with real User IDs and addresses: Activate the Flow in a sandbox and trigger the notification. Verify delivery in the notification bell, inbox, Slack, or SMS as appropriate. Debug mode shows the action execution but not delivery confirmation.
7. Review limits before go-live: Confirm email volumes are within org limits. For custom notifications on high-volume automations, calculate worst-case hourly send rate against the 1,000/hour cap.

Review Checklist

• Custom Notification Type exists in Setup before the Send Custom Notification action is used
• recipientIds for Send Custom Notification is a User ID collection, not email addresses or Contact IDs
• Send Email body uses a Text Template resource or inline text — not a Classic Email Template reference
• Every notification action has a fault connector wired to a log or admin alert
• Estimated send volume is within org email limits and custom notification hourly limit
• SMS or Slack actions are only configured in orgs with the required add-on or integration
• Merge fields in notification body use {!variableName} syntax (HTML tags are ignored in bell notifications)
• External-email recipients come from validated fields (not free-text user input)
• Bulk notifications have a rate-limit gate (Pattern 3)

Salesforce-Specific Gotchas

1. Custom Notification recipientIds must be User IDs, not email addresses — The Send Custom Notification action requires Salesforce User record IDs (15 or 18-character). Passing an email address string causes a runtime error that is often reported as "notification not delivered" rather than a clear field-level error.
2. Send Email does not use Classic Email Templates — Flow's Send Email action cannot reference a Letterhead or Classic HTML template from Setup. Body content must come from a Flow Text Template resource or an inline text value. Practitioners who expect template-driven emails must use an Email Alert action instead.
3. The 10,000 notification-actions/hour org limit drops notifications silently — a fault connector will NOT catch it — Salesforce documents that beyond the cap "no more notifications are sent in that hour, and all unsent notifications are lost," resuming next hour. No exception is thrown, so the flow does not fault and does not roll back, and there is no fault email. Detection requires your own instrumentation, not error handling.
4. SMS is invisible without Digital Engagement — no fallback action appears — If the Digital Engagement add-on is not provisioned, the Send SMS action does not appear in Flow Builder at all. There is no placeholder or error message.
5. Slack Post Message requires an active connected workspace, not just package installation — Installing the Salesforce for Slack managed package does not automatically make the action work. An admin must authenticate and connect a Slack workspace in Setup.
6. Custom Notification title is capped at 250 characters (body 750), but desktop truncates the display far earlier — titles render to about 120 characters and bodies to about 320 before an ellipsis. Do not conflate the two numbers: 250/750 is what the API accepts, 120/320 is what a user reads. Front-load the actionable text.
7. Email deliverability setting "No access" blocks all outbound emails — Sandbox orgs default to this setting; Flow's Send Email succeeds in the flow but nothing leaves the org. Verify deliverability is All email in Setup before testing.
8. Custom Notifications to inactive users don't error but don't deliver — Filter recipient collections by IsActive=true before passing to the action.
9. Slack message character limit (~40k) + formatting caveats — Slack truncates long messages; BlockKit JSON isn't supported from the standard Flow action.
10. Digest patterns need state to work correctly — aggregating notifications across flow runs requires a counter object; don't try to do it within a single run.

Proactive Triggers

Surface these WITHOUT being asked:

• Send Email action without fault connector → Flag as High. Failed sends silent.
• Send Custom Notification sending to email-address string (wrong input type) → Flag as Critical. Will fail at runtime.
• Bulk notification in record-triggered Flow without rate-limit awareness → Flag as High. Risk of cap exhaustion.
• Digital Engagement / Slack action used without license check → Flag as Critical. Deploy-time failure.
• Inactive-user filter missing on notification recipient collection → Flag as Medium. Wasted notification attempts.
• Sandbox testing without deliverability check → Flag as High. Flow works in sandbox but doesn't actually send.
• Custom Notification Type not version-controlled → Flag as Low. Deployment drift risk.
• Slack channel ID hardcoded instead of pulled from Custom Metadata → Flag as Medium. Environment-brittle.

Output Artifacts

Related Skills

• admin/email-templates-and-alerts — Use when the requirement involves managing Classic Email Templates, Email Alerts, or letterhead templates in Setup.
• flow/fault-handling — Use alongside this skill: every notification action needs a fault connector designed intentionally.
• admin/flow-for-admins — Use for broader Flow type selection when notification is one of several automation requirements.
• flow/record-triggered-flow-patterns — when the notification fires from a record trigger and must be bulk-safe.
• flow/flow-bulkification — when bulk notification volume is approaching limits.