I first set up an import definition where the file naming pattern matches exactly a csv placed on our FTP. The definition runs and data is imported exactly how i want it into a data extension. Once i change the file naming pattern to %%FILENAME_FROM_TRIGGER%% and then place the import activity into an automation with a file drop setup to get a filename to begin with a naming convention, the automation fails with ERROR: Import failed: File [filename]_1.csv.filepart not found

The csv files generated do not have dates so i can't use a date wildcard to go around this. Is there anything else i can do? I have 42 files coming in nightly, named the same at the beginning followed by _1, _2, _3... to _42.csv

  • As much of a cop-out as this may sound, try recreating the import definition from scratch and if that does not resolve it. Recreate the automation. I have pretty much this exact process you listed above running successfully, so it may just be some sort of corruption of the activities causing your issue. Commented Feb 28, 2020 at 15:18
  • Just for completeness in this answer, i tried both the above to no avail :( Commented Mar 4, 2020 at 8:47

1 Answer 1


My best guess here is the file is being renamed between triggering the automation and reaching the import activity. And I am not talking about something.csv to whatever.csv, but more on the filename extension. Without being expert in the area of FTP, I have seen following behaviour in few cases:

  1. When initiating the file transfer, a file is being created on the FTP server, with the name: yourfile.csv.filepart
  2. You can see the size growing while data is being transferred to the server
  3. Once all the data has been transferred, you see the file change the extension to the actual data extension, e.g. .csv
  4. If you create your import definition with %%FILENAME_FROM_TRIGGER%%, your import will fail, as import activity is asked to look for yourfile.csv.filepart, which is called yourfile.csv by now
  5. This is logical, as the trigger gets fired as soon as a new file is placed in the FTP folder

You can overcome this by using %%FILENAME_FROM_TRIGGER_BASE%%, or %%BASEFILENAME_FROM_TRIGGER%%.csv - to be entirely sure. You can see the various options for these substitution strings in this list.

Both examples strip the last filename extension (.filename in yourcase), and leave you with yourfile.csv for the import activity to use.

  • 1
    great insight! Thanks I never knew that the trigger automation listener would grab it as 'filepart' when dropped. Commented Mar 2, 2020 at 15:42
  • great stuff thanks! This issue solved itself after an overnight run but now I will be updating definitions as per this answer, this could have much less painful if i had done this first time! Commented Mar 4, 2020 at 8:44
  • 1
    @Gortonington - imagine my own frustration when I was debugging this issue the first time. I can’t speak highly enough about %%BASEFILENAME_FROM_TRIGGER%% Commented Mar 5, 2020 at 2:22
  • Keep in mind, %%BASEFILENAME_FROM_TRIGGER%% appears to not contain any folder/directory structure in the filename. In other words, if your file-drop trigger is for anything in the Import/FolderABC folder, the basefilename arg isn't going to look inside of FolderABC.
    – WEFX
    Commented Feb 19, 2021 at 19:37
  • 1
    @wefx - not for reasons other than naming, as discussed in this thread Commented Feb 19, 2021 at 23:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .