📩 Learning 8 - Today's Paper Isn't Always There Yet: A Small SFMC Import Activity Error With a Big Lesson

Recently, I was setting up an Import Activity in Salesforce Marketing Cloud (SFMC) as part of a larger automation.

I did everything the way I normally would:

• Set up the SFTP folder structure correctly
• Uploaded a sample CSV to validate the format
• Used clean attribute names with no trailing spaces
• Matched data types and field mapping precisely
• Used a date-based personalization string as the file name suffix: filename_%%Day%%%%Month%%%%Year%%.csv

Everything checked out. I expected the import to run cleanly on the very first attempt.

Instead, I got this:

Import failed: File not found matching the pattern

The strange part? When I manually searched for the file afterward, it was right there, named exactly as expected. The pattern was correct. The file existed. And yet, the scheduled run had failed.

That contradiction — found when I looked, missing when it ran — reminded me of something very ordinary from home: waiting for the morning newspaper.

📬 The Scenario: Is Today's Paper Here Yet?

Every household with a newspaper subscription knows the rhythm.

• Yesterday's paper, last week's paper, last month's paper — all sitting safely in the pile or the archive. You can go pick any of them up right now, no uncertainty at all.
• Today's paper — printed and dated for today, but only actually usable after the paperboy has made his round.
• Tomorrow's paper — doesn't exist. Won't exist until tomorrow. No amount of checking the doorstep will produce it early.

Now imagine someone walks out at 6 AM, sees no paper on the doorstep, and declares, "The subscription is broken, today's paper doesn't exist."

That's not quite right. Today's paper does exist — it's dated correctly, it was printed — it just hasn't been delivered yet. By 8 AM, the same doorstep has it, exactly as expected.

Past = always available. Present = available, but only after a certain point. Future = never available, no matter when you check.

This turns out to map almost exactly onto what happened with my date-based Import Activity.

🚪 The Doorstep = The SFTP Folder

The SFTP folder is where the file is expected to "arrive" — just like the doorstep is where the newspaper is expected to land every morning.

The folder itself was never the problem. It was always there, ready to receive the file, the same way the doorstep is always there, ready to receive the delivery.

🗓️ The Date Printed on the Paper = The File Naming Pattern

Every copy of the newspaper is printed with a date on the masthead, so you know at a glance whether it's fresh or old.

In the same way, %%Day%%%%Month%%%%Year%% in the file name pattern is SFMC's way of saying: "look for the file dated for today."

The pattern itself wasn't wrong. It correctly describes what a valid file for "today" should be named.

📚 The Archive Pile = Past Dates, Always Safe

If you ask for yesterday's paper, or last Tuesday's, there's no ambiguity — it's already been printed, delivered, and sitting in the pile. You can retrieve it with total confidence, any time of day.

This is why files for past dates almost never cause this kind of failure. By the time you're looking for them, delivery has long since happened. There's no race condition left to worry about.

⏰ Checking at 6 AM vs. 8 AM = Automation Run Time vs. File Arrival Time

This is where the real gap shows up — and it's entirely about today, not yesterday or tomorrow.

The person checking the doorstep at 6 AM is the equivalent of the Import Activity running on its scheduled trigger time. If the file — today's "delivery" — hasn't actually landed on the SFTP by the moment the automation checks, it has no choice but to report:

Import failed: File not found matching the pattern

Later, when you go check manually — after the file has actually arrived — of course it's there. You checked after delivery. The automation checked before.

"Found when I search, fails when it runs" is almost always a timing story about today, not a problem with the pattern.

🚫 Asking for Tomorrow's Paper = Requesting a Future Date That Can't Exist

There's one more case worth calling out, because it's a different problem entirely: asking for a file dated ahead of when it could possibly exist.

No amount of re-running the automation, adjusting the schedule, or waiting a few extra minutes will produce a file for a date that hasn't happened yet. If the pattern or logic accidentally resolves to a future date, the fix isn't timing — it's the date logic itself.

This is the one genuinely different failure mode from the "today, too early" case, and it's worth ruling out separately before assuming everything is just a delivery-timing issue.

🔧 What This Looks Like in Practice

File naming pattern used:

filename_%%Day%%%%Month%%%%Year%%.csv

Error received on scheduled run:

Import failed: File not found matching the pattern

Behavior observed:

• Pattern is syntactically correct
• File is present when checked manually after the fact
• Scheduled automation run fails at its trigger time

Where to look:

• Whether the file-generation system and the Marketing Cloud account are operating in the same time zone
• Whether there's any buffer between "file expected" and "file guaranteed to exist"
• Whether the date logic could ever resolve to a future date by mistake, as opposed to just running early
• Whether a file-drop-triggered automation (rather than a fixed time-based schedule) would remove the guesswork entirely

💡 What I Learned

My first instinct was to suspect the pattern itself — maybe a stray space, a wrong date token order, or a case-sensitivity issue.

But the real issue wasn't what the pattern said. It was when the pattern was being evaluated against a file that may not have existed yet at that exact moment.

Past dates were never the issue — those files were always safely delivered by the time anyone went looking. Future dates would have been a genuinely different, impossible request. The actual failure lived entirely in that narrow window on the same day — checking for today's delivery before today's delivery had happened.

📌 Key Takeaways for SFMC Practitioners

• A "File not found" error with a technically correct naming pattern is often a timing issue, not a pattern issue — manually finding the file later doesn't disprove the failure, it just means you checked after delivery instead of before.
• The current date is the risky window: files are only reliably available after the source file has actually landed, so a scheduled run that fires too early will fail even with a perfectly valid pattern.
• If the pattern ever resolves to a future date, no amount of retrying or rescheduling will help — that's a date-logic problem, not a timing one.

🧭 Conclusion

Sometimes the smallest errors aren't about what you configured, but when the system goes looking for it.

Thinking of the Import Activity as someone checking the doorstep for the morning paper helped me separate three very different situations that all look like the same error: yesterday's paper (always safe), today's paper (safe only after delivery), and tomorrow's paper (never safe, because it doesn't exist yet).

So the next time an import fails with a perfectly valid file name pattern, before touching the pattern itself, ask: is this a past date, a today that hasn't arrived yet, or an impossible future date? The answer changes everything about where to look next.

Note – These are simply my observations and learnings while troubleshooting this. Always refer to official Salesforce documentation and Salesforce Support guidance for the most accurate and up-to-date information.

Salesforce Help article:

https://help.salesforce.com/s/articleView?id=000381433&type=1

I hope you found this useful. If you've run into this "found it manually, but the automation says otherwise" pattern before, I'd love to hear how you solved it. 🚀