We started experiencing a group of automations failing. Automations that hadn't failed in the past but for some reason began to fail upon the file transfer activity. When I look at the file transfer activity, an eye symbol is now appearing stating that other file activities may use this same location. I looked through SF documentation and didn't see anywhere this would be an issue.

I removed the dynamic attributes in the file transfer ask, and the transfer works, however when I revert back to the dynamic part of the file naming convention (year, month, day, minute, second) it fails. I'm stumped. Any thoughts? enter image description here enter image description here

  • Typically, you'd use %%FILENAME_FROM_TRIGGER%% as the file name pattern on your File Transfer Activity for a File Drop Automation. Does that fix your issue? – Macca Jul 15 at 23:54
  • That's the thing, we were originally utilizing %%FILENAME_FROM_TRIGGER%%, but it began erroring out, even though it had run successfully before. Could it have something to do with the file location? The eye also appeared at the same time that it started erroring out, so that seems to be the source of the issue. I just don't know how it relates. – chorlesbarkley7 Jul 16 at 14:23
  • A bit of a long shot, but your file names are pretty long, if you're adding a datestamp to the end. Could you test reducing the side of that prefix that goes before your date to see if there's some sort of undocumented limitation on lengths of filenames, maybe? – Macca Jul 16 at 23:56
  • Unfortunately @Macca we have automations with longer names that seem to work fine. Very strange overall. – chorlesbarkley7 Jul 17 at 19:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.