電商客戶運營自動化，發送個性化優惠券郵件。優惠券碼源於「優惠券庫」DE——預建批次碼，每碼僅用一次。庫空之後，郵件發送時%%CouponCode%%呈現空白。客戶收得無優惠券之郵件。
事後糾正，苦不堪言。預防之，舉錯活動__JHSNS_SEG_8dccad93_4__，易如反掌。
翻译 RaiseError 活动之能
RaiseError 乃自动化之活动也。其审于所定之状，若状示其败，则自动化中止，生错误——下游活动皆不施行。
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)
既触发报错，则自动化中止。当通知配置收件人。团队修正前提（此例中，重载券库），再行运行。
设立
于自动化工坊，于检验SQL查询活动后，增置报错活动。配置之：
- 条件：何种境遇下报错
- 错误信息：告警应言何如
- 严重性：日志层级（错误抑或警告）
- 告警接收者：触发时谁得电邮
合乎之式
前置之验
发电邮之务，先验所需之资存否：
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
每项检查皆廉，每项皆能捕获特定之失效模式
商业规则之验证
验证运营之规则：
RaiseError if:
- Send attempted outside business hours (weekend send needs approval)
- Audience exceeds send classification limit
- Campaign ID not in approved campaign list
更趋治理之导向。强制执行不应被偶然规避之规则
抛出错误与验证活动
并止诸务。异途有之：
验事之务
揭谬之务
纳言
一数据之延
凡可表于SQL之状
察
行数合乎所期之域
任一自造之真值
权变之能
惟计行数而已
任意逻辑
设置
基于界面，迅捷
需支持SQL查询
用验证以查"受众行数是否合理？"此乃常情之八成也
用抛出错误 若情状繁复——"券库可有足额码否"、"主DE是否于时辰之内更新"、"今日是否为禁发之期。"
错谬一：竟无前件之检
团队设自动化以发邮件，然无前件。及至数据谬误，邮件失当。团乃自怒客之口得之。
修之：凡生产自动化，若以发邮件终者，必具一预条件——行数之检、新度之验、或商规之约。或举错、或验真，择器宜之。
过二：条件过苛
举错设制，若券库< 1000. 常态运行时，每夜重载前或降至五百。自动化无故停摆，邮件不达，活动失时。
修正：设阈限，既察实弊，复容常异。多设零上，如“若不及预期之十”而非“若不及百”。
误三：未设通知受者。
触发报错而无人知之。自动化悄然止步。团队方觉其弊，乃问“今日之邮件何故未发？”
解：恒设通知受者。或值班者别名，或团队之邮，若不足此，则自动化主事者亦当知之.
合并检查之式
要害之发，须多前提相续：
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
有三停顿之状。任何失败皆止发送，免有损伤。团队已知悉
此模式尤适于高风险发送——重大活动启动，财务通知，法律披露之属
仅于营业时间引发错误
夜半或有预期之状（批处理作业运行）。唯于营业时间引发错误：
SELECT CASE
WHEN DATEPART(hour, GETDATE()) BETWEEN 9 AND 17 THEN 1
ELSE 0
END AS DuringBusinessHours
于触发错误之境，用此果。自动化行于子时，勿扰人，惟条件实谬则可。
监察与警醒
触发错误之报，达于所设之受者。于生产自动化，导之：
- 值班轮换（使常有人见之）
- 公共警讯之途（Slack, PagerDuty)
- 团队之监察系统
唯邮讯者易失。宜与团队既观之器相合.
所得之益
举错之活动，乃制器之停也。当境况复杂于行数（验真之事也），而需任意之理，则用之。凡制器发信者，必有一预条件。五分钟之设防，可免“众得空券”之问询。
于客户SFMC账户强固制器乎？吾Salesforce之众，于生产事务中，常运可靠性之范，并合监测之术。相接>
睹吾全貌平台之务所涉栈者。