Naming conventions are sometimes buggy in subfolders.

After testing this some more, when you apply a naming convention, it becomes an automation immediately for that folder, and subfolders if you've enabled that feature. 

Could you attach a screenshot showing the options you get on the parent folder?

The parent folder still doesn't have a naming convention option... Why is this?

If you wish, you can try and see how that works on your implementation. 

Just so you're aware, there's no guarantee it'll work correctly on previously uploaded files

So if I remove the automation, I'll get the naming convention option back?

Since the naming convention is inside an automation in the parent folder, as opposed to just a naming convention, this process is only run once, meaning that it won't be able to run on the previous files.

Otherwise, this could lead to it endlessly repeating the automation and making file names longer and longer forever.

I think that worked, but all my previous files are not affected, where if I put the convention in the file request, it fixes all the names.

I'm confused why my parent folder doesn't have a naming convention option anymore, only an automation option that only seems to apply when new files are uploaded, so the old ones aren't renamed

Thanks for the images. I've managed to replicate the same behavior you mentioned, and after a lot of testing, I was able to figure out how to avoid this, and more importantly, why this is happening.

Long story short, to prevent this from occurring in subfolders, on the File request page, click the 'Set naming conventions button' there:

Then, for the next window, remove the Sender's name option entirely so it looks like this.

The folder I chose is a subfolder of a page with the exact automation you created, and all files came out with the correct name.

Now, if you want to know why this was occurring, because file requests automatically add the sender's name in the default naming convention after the filename, this means that files would look like 'test1 Jay.png'.

After doing the tests, my belief is that Dropbox can only access the 'sender's name' once in total. So, when the automation tried to add a sender name, it couldn't access it, and left it blank.

The filename itself, which is then added by the automation 'correctly' would be the test1 Jay.png, which was generated by the original naming convention in the file request, hence the wrong order you were seeing (with sender name and filename in a different order on your end).

When you remove the sender's name from the original file request, the parent folder automation would be able to grab that variable, and then put it in the correct order.

Could you test this out and let me know if this helps?

Please could you attach a screenshot showing the exact settings you have for the naming convention, or automation, for the parent folder?

It shouldn't be possible to add the sender from the normal naming conventions page or automation settings. It should only be visible from the file requests page, or an already existing naming convention if it was previously applied.

Also, the date format you've mentioned doesn't seem to be an option on the site.

Ok, an example is
"01-01-1970-12.34 - _ MasterFolder _ Testman - 1234.pdf"
when it's supposed to be
"01-01-1970-12.34 - Testman _ MasterFolder _ 1234.pdf"

The parent folder doesn't have the option to make a naming convention anymore, only an automation.
I thought I put a convention on the parent folder before, but it's been a confusing process...