MobileConnect Import Definition to create new list each time

Question

I've just started using an automation which imports a list of MobileConnect contacts into a list called SMS_Master.

The mapping works fine and the file drop trigger works great. However, we run multiple SMS campaigns a day and need to keep separate lists, as one subscriber might appear in more than one campaign. Is there a way to take the file name of the csv placed on the FTP, and create a new list in which to put the contents?

Answer 1

I am gonna say that it is a 'No, not really' unfortunately. Although those would be awesome capabilities, I do not believe SFMC has these capabilities available (can always talk to your account rep and maybe they can build some custom capabilities/tools for you)

Users currently have no way to have access to the filename on FTP for manipulation outside the Import/File Transfer personalization strings (eg %%FILENAME_FROM_TRIGGER%%). This makes it impossible to utilize filename for list delegation.

The REST API around Mobile Connect lists seems very restrictive and aimed more at execution than data manipulation/maintenance, meaning creating apps or scripts might not be a solution either.

The best workaround I can think of for you would be:

1. Develop a naming pattern for your data files dropped to the FTP that mimic the campaign you want. (e.g. campaign1.csv)
2. Create an import definition for each campaign, but have the target MC List be the corresponding campaign. E.g. for Campaign1 import goes to Campaign1 MC List, Campaign2 goes to Campaign2 MC List, etc.
3. Create X Triggered automations (where X is the number of lists you have). Each one focusing on the directory where you currently drop, but have the trigger look for the specific naming convention defined in #1. (e.g. Automation Campaign1 looks for 'Starts with' 'Campaign1')
4. In each of these automations, place in the corresponding Import definition you created in #2. (e.g. insert import campaign1 into automation campaign1)

This is a bit unwieldy and is far from scalable, but should help your immediate needs. Hopefully SFMC will find a better solution for this in the future, but to my knowledge this is the best way currently to handle it.