SapotaCorp

SFMC Automation Alerts: Why Only One Setting Actually Sends Email

Automation Studio has two notification settings that look similar and do different things. The global one is weak. The per-automation Run Completion alert is the one you actually want configured.

Key takeaways

  • Automation Studio has 2 notification settings that look similar. The global Notification Settings sends to one email on system-wide events (weak — admin-level only). The per-automation Run Completion alert sends per automation on success/failure (the one production teams actually want).
  • Per-automation Run Completion alert configures Email Recipients for failure events. Set this on every production automation; without it, failures sit silently until a downstream report shows missing data days later.
  • Common mistake: configuring only Notification Settings and assuming it covers automation failures. The global setting fires on bigger events (account-level issues); individual automation failures only surface through the per-automation alert. The 2 settings are not redundant — they cover different layers.
  • Include failure context in the alert. The default notification is generic ("automation X failed"); add a custom Activity that captures the failing step, record count, and last successful run. Alert with context lets operations investigate in minutes instead of hours.
SFMC Automation Alerts: Why Only One Setting Actually Sends Email

Automations in SFMC that run at 2 AM don't have anyone watching them. When they fail, the next person to notice is usually the client the next day, asking why the scheduled email didn't go out. By then the damage is done.

The fix is straightforward: configure failure notifications so humans get emailed when the automation exits with an error. SFMC has two places to do this, and only one of them is useful.

Where to configure it (the right way)

Inside any Automation, go to its Activity tab. Scroll to the Run Completion section. There's a field labeled something like "Send notification on completion to:" followed by a text box.

Enter a comma-separated list of email addresses. SFMC will email each one when this specific automation finishes - success or failure.

This is per-automation. Each automation needs its own Run Completion configured. Missing this on a new automation means that automation fails silently.

Include at minimum:

  • The tech lead on the SFMC side.
  • A functional contact on the client's side.
  • A shared distribution or channel email, not just one person - people take leave.

Avoid adding only one individual's inbox. The day the automation fails is usually the day they're on vacation.

Where not to rely on (the trap)

In the Automation Studio Overview page, there's a section called Notification Settings. This is an account-level setting, not per-automation. It controls notifications for the Automation Studio tool as a whole, at a different abstraction layer.

Teams new to SFMC often set the account-level Notification Settings, assume they've covered all automations, and then wonder why specific automations still fail silently. The account-level setting does not replace Run Completion alerts.

Configure both, but rely on Run Completion. Every new automation you ship, go check its Run Completion field before go-live.

What the notification looks like

When an automation fails, the notification email from SFMC includes:

  • Automation name
  • Time it ran
  • Which Activity failed (often just the number / position, not always the name)
  • A basic error message

The error message is often cryptic ("Activity failed" or "The import failed"). Use it as a trigger to log into SFMC and check the Automation history, not as a complete diagnosis.

Combining with Verification Activity

Verification Activity (covered in a separate post) has its own notification config. When Verification fails mid-automation, the Verification alert fires to the Verification's own email list; the Run Completion alert still fires at the end of the automation.

This is actually useful: the Verification alert tells you what went wrong (bad input), the Run Completion alert confirms the automation halted and the send did not execute.

Monitoring beyond SFMC's native alerts

Native SFMC notifications are basic. For engagements that need more robust monitoring:

  • Pipe the notification emails into a shared channel (Slack, MS Teams) via email-to-channel integrations.
  • Add a lightweight external check: a scheduled task elsewhere that queries _Automation_Activity data view and alerts if expected automations didn't complete.
  • For high-volume sending, integrate with an external monitoring tool (Datadog, PagerDuty) through Webhooks or email bridges.

For most mid-market builds, the native Run Completion emails plus a shared Slack channel are enough.

Pre-go-live checklist

Before declaring any production automation "live," confirm:

[ ] Run Completion email list is populated
[ ] At least one non-individual email (shared inbox or distribution list)
[ ] Verification Activity configured if this automation imports a file
[ ] Verification's own notification email list is populated
[ ] Test run: manually trigger the automation, confirm you receive the email

The last step catches the simplest bug: you typed the email into the wrong field, or the email was misspelled, or the notification option was never actually enabled.

Takeaway

Automations don't notify themselves by default - you have to configure it per-automation in the Run Completion section. The account-level Notification Settings is a different tool and doesn't cover you. Add failure alerts to every production automation on day one, include a shared distribution email, and run a test send before declaring it done. It's 5 minutes of setup that saves a weekend of fire-fighting.


Production-hardening SFMC automations? Our Salesforce® team configures monitoring, alerts, and pre-go-live checklists on production Marketing Cloud builds. Get in touch ->

See our full platform services for the stack we cover.


Need senior engineers for SFMC implementation, integration, or migration? See Sapota's Salesforce services — Marketing Cloud, Revenue Cloud, Sales Cloud, and Service Cloud delivery from $1,800/engineer/month.