吾等银业之务，有日自动化之程，取应得付款提醒之客户文件，逐一电邮之。此生产级管道，洁净运行数月矣。

一日，上游系统有误。所输出之文件含五十条记录，非尙常之万计。自动化依时运行，导入五十行，并致函五十客。其余九千九百五十客未得提醒。客户收账之众，二日后方觉其缺，时已过数账之期矣。

此发送本身非误。其输入 误矣，自动化之中无有察之者。

验证之事，其修

自动化之室有行名验证，其职惟一：验数据之延之行列数，若数非所期，则止自动化。

置之于导入与发送之间：

Schedule Starting Source
  -> Step 1: Import File Activity
  -> Step 2: Verification Activity   (fail if DE has fewer than 8,000 or more than 15,000 records)
  -> Step 3: Send Email Activity     (only runs if Verification passes)

若验证失败，则自动化程序戛然而止。后续诸务皆不运行。系统将向汝所配置之电子邮箱地址发送通知.

设定阈限之配置

验证活动支持：

• 最小记录数 - 若行数低于此数，则自动化失败
• 最大记录数 — 若行数逾此，自动化即告败
• 二者皆 — 乃所期之运行区间

就银行之例，其解乃：

DE: Payment_Reminder_DE
Minimum: 8000
Maximum: 15000

凡文件出此界外，即自疑，而发信之步不果行。

定阈之道，权衡也。

• 过紧：自动化于寻常波动（月终与月中）失灵，徒劳烦扰他人。
• 过宽：实败漏逸，盖因"自零至百万间"非有义之域也。

吾之准则：察其卅日之内行列之数，取其最寡与最众，而各增其廿五。此法可察灾变之失（如空檔、十倍之膨），而不误于常变之异。

警报所至

验真之务有自设之通报之制，别于自动化之程成之讯。宜设之使电邮：

• 客户之功能团队（其上游任务已败）。
• SFMC方之内部技术领袖。
• 共享之信道或分发名单，非一人之收件箱——众人皆可休假。

任何触及文件之自动化，何以要紧

文件败于可预之途：

• 上游任务失错，导出零或部分结果。
• 时区计算有误，文件含昨日行重复。
• 模式已变，导入活动载空列。
• 源系统在文件生成时中断。

无验，则自动化将欣然送诸所入之数据。其弊惟显于人觉下游之业效——此恒已晚矣。

凡生产自动化，自进口文件发邮件者，验核之务实属必行。

何时而可略验

交易自动化——订单确认、密码重置等——勿用验证。每触发一次，发一封邮件。所谓“行数”之概念，不适用焉。

开发自动化，于早期构建时，可暂略之。须于首度生产部署前，加之。

要旨

验证活动乃SFMC自动化所能加之最廉之保险也。其能于不良输入未成顾客之谬误前即行捕获，而配置之需时约五分钟耳。于任何既存之生产自动化中导入文件并发送群发邮件者，皆可加装之——及至需之之日，方知其有之之幸也.

欲使SFMC自动化生产加固乎？ 吾Salesforce之众，于既有之Marketing Cloud管道，增验证、监控、警之能。 欲相知者，>

请参吾之全 平台服务，以观吾所覆之栈。