One of our banking engagements had a daily automation that imported a file of customers due for payment reminders and emailed each one. Production-quality pipeline, running clean for months.

One morning the upstream source system had a bug. The file it exported contained 50 records instead of the usual ~10,000. Automation ran on schedule, imported the 50 rows, and sent reminders to those 50 customers. The other 9,950 never got their reminder and the client's collections team discovered the gap two days later, after the due date had passed on several accounts.

The send itself wasn't wrong. The input was wrong, and nothing in the automation noticed.

Verification Activity, the fix

Automation Studio has an Activity called Verification whose only job is: check a Data Extension's row count, and stop the automation if the count is outside an expected range.

Inserted between Import and Send:

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)

When Verification fails, the automation stops right there. Subsequent Activities don't run. A notification goes out to whichever email addresses you configured.

Configuring the thresholds

Verification Activity supports:

• Minimum record count - automation fails if row count is below this
• Maximum record count - automation fails if row count is above this
• Both - the expected operating range

For the banking case, the fix was:

DE: Payment_Reminder_DE
Minimum: 8000
Maximum: 15000

Any file outside that window is automatically suspect, and the Send Email step won't execute.

Picking the thresholds is a trade-off:

• Too tight: the automation fails on normal fluctuations (end of month vs. middle of month), pages someone unnecessarily.
• Too wide: real failures slip through because "anything between 0 and a million" isn't a meaningful range.

Our rule of thumb: look at the last 30 days of row counts, take the min and max observed, and pad by 25% on each side. That catches catastrophic failures (empty file, 10x bloat) without tripping on normal variance.

Where the alert goes

The Verification Activity has its own notification configuration, separate from the automation-level Run Completion notifications. Configure it to email:

• The client's functional team (they need to know their upstream job failed).
• The internal tech lead on the SFMC side.
• A shared channel or distribution list, not a single person's inbox - individuals go on leave.

Why this matters for any automation touching a file

Files fail in predictable ways:

• Upstream job errored, exported zero or partial results.
• Timezone math went wrong, file contains yesterday's rows twice.
• Schema changed, Import Activity loaded empty columns.
• Source system had outages during file generation.

Without Verification, the automation will happily send to whatever data made it in. The problem only becomes visible when someone notices the downstream business effect - which is always too late.

For any production automation that sends email from an imported file, Verification Activity is effectively mandatory.

When to skip Verification

Transactional automations - order confirmations, password resets - don't use Verification. They send one email per trigger. The "row count" concept doesn't apply.

Development automations can skip it during early build. Add it before the first production deploy.

Takeaway

Verification Activity is the cheapest insurance you can add to an SFMC automation. It catches bad input before it becomes a customer-facing mistake, and it takes about five minutes to configure. Retrofit it on any existing production automation that imports files and sends mass email - the day you need it, you'll be glad it's there.

Production-hardening an SFMC automation? Our Salesforce team adds Verification, monitoring, and alerting on existing Marketing Cloud pipelines. Get in touch ->

See our full platform services for the stack we cover.