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.

Schedule Starting Source
  -> SQL Query Activity (count remaining coupons)
  -> RaiseError Activity (halt if coupons < 100)
  -> Send Email Activity (runs only if RaiseError didn't trigger)

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:

RaiseError if:
  - Coupon bank DE < 100 rows
  - Audience DE < expected minimum
  - Required field in audience DE is null in too many rows
  - Dependency DE hasn't been refreshed today

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

Business rule validation

Validate operational rules:

RaiseError if:
  - Send attempted outside business hours (weekend send needs approval)
  - Audience exceeds send classification limit
  - Campaign ID not in approved campaign list

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

RaiseError vs Verification Activity

Both halt automations. Different use cases:

Verification Activity

RaiseError Activity

Input

A Data Extension

Any SQL-expressible condition

Check

Row count within expected range

Any custom boolean

Flexibility

Row count only

Arbitrary logic

Setup

UI-based, fast

Requires 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:

Automation:
  -> SQL Query (count coupons in bank)
  -> RaiseError (halt if coupons < minimum)
  -> SQL Query (check audience refreshed today)
  -> RaiseError (halt if audience not refreshed)
  -> Verification Activity (halt if audience row count outside range)
  -> Send Email Activity

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:

SELECT CASE
  WHEN DATEPART(hour, GETDATE()) BETWEEN 9 AND 17 THEN 1
  ELSE 0
END AS DuringBusinessHours

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.