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.