RaiseError Activity: Halting Automations When Something is Off

E-commerce client runs an automation that sends personalized coupon emails. The coupon code comes from a "coupon bank" DE - prebuilt batch of codes, each used once. When the bank empties, emails ship with %%CouponCode%% rendered as blank. Customers receive a coupon email with no coupon.

Fixing it after the fact is painful. Preventing it with RaiseError Activity is easy.

What RaiseError Activity does

RaiseError is an Automation Studio activity. It evaluates a condition you define. If the condition indicates failure, the automation halts with an error - no downstream activities run.

When RaiseError triggers, the automation stops. Notification is sent to configured recipients. Team fixes the precondition (in this case, reloads the coupon bank) and re-runs.

Setup

In Automation Studio, add a RaiseError Activity after the check SQL Query Activity. Configure:

• Condition: under what circumstances to raise error
• Error message: what the notification should say
• Severity: log level (error vs warning)
• Notification recipients: who gets emailed on trigger

Patterns that fit

Precondition checks

Before a Send Email Activity, verify required data exists:

Each check is cheap. Each catches a specific failure mode.

Business rule validation

Validate operational rules:

More governance-oriented. Enforces rules that shouldn't be bypassed even accidentally.

RaiseError vs Verification Activity

Both halt automations. Different use cases:

Verification ActivityRaiseError ActivityInputA Data ExtensionAny SQL-expressible conditionCheckRow count within expected rangeAny custom booleanFlexibilityRow count onlyArbitrary logicSetupUI-based, fastRequires supporting SQL query

Use Verification for "is the audience row count reasonable?" It's the 80% case.

Use RaiseError when the condition is more complex - "does the coupon bank have enough codes," "has the master DE been refreshed within the last hour," "is today a blocked send date."

Mistake 1: No precondition checks at all

Team builds an automation with Send Email Activity but no preconditions. When the data is bad, the email goes out wrong. Team finds out from angry customers.

Fix: every production automation that ends with Send Email should have at least one precondition - row count, freshness check, or business rule. RaiseError or Verification, pick the right tool.

Mistake 2: Overly strict conditions

RaiseError configured to halt if coupon bank < 1000. Normal operations sometimes dip to 500 before the nightly reload. Automation halts unnecessarily, email doesn't go out, campaign misses the window.

Fix: set the threshold at a level that catches real failures but accommodates normal variance. Usually set it just above zero - "halt if less than 10% of expected" rather than "halt if less than 100%."

Mistake 3: No notification recipient configured

RaiseError triggers but nobody is notified. Automation halts silently. Team discovers the issue when someone asks "why didn't today's email go out?"

Fix: always configure notification recipients. Oncall alias, team email, or at minimum the automation owner.

Combined check pattern

For critical sends, multiple preconditions in series:

Three halting conditions. Any failure stops the send before damage. Team notified.

Pattern works especially well for high-stakes sends - major campaign launches, financial notifications, legal disclosures.

RaiseError during business hours only

Some conditions are expected after hours (batch job running). Only raise error during business hours:

Use the result in the RaiseError condition. Automation runs at 3 AM don't wake anyone up unless the condition is genuinely wrong.

Monitoring and alerting

RaiseError notifications go to configured recipients. For production automations, route to:

• Oncall rotation (so someone always sees it)
• A shared alerting channel (Slack, PagerDuty)
• The team's monitoring system

Email-only notifications get lost. Integrate with the tools the team already watches.

Takeaway

RaiseError Activity is the controlled stop for production automations. Use when conditions are more complex than a row count (that's Verification's job) and you need arbitrary logic. Every production automation that sends email deserves at least one precondition. Five minutes of setup prevents the "why did everyone get a blank coupon?" support ticket.

---

Hardening production automations on client SFMC accounts? Our Salesforce team ships reliability patterns with monitoring integration on production engagements. Get in touch ->

See our full platform services for the stack we cover.