I finally got my thinking cap on. Not sure how robust or efficient this is, so please feel free to chip in if you think you can improve it. Try it out and watch for incremental Test folders being created on the desktop.
I'd worry about the "If Local__Path contains..." test -- what if a folder higher up the tree has the new folder name as a substring? Perhaps change that to "Local__Path ends with /%Variable%Local__FolderName%" for safety?
Anyways, as a fan of the brain-dead loop, here's another take on it (which I'm sure could be improved):
It appears that the "Create New Folder" action returns "OK" even when the action does nothing because the folder already exists, ie it fails gracefully but silently so there's no error to Catch.
It is always problematic to change an existing behaviour. It can lead to macros suddenly stopping working and producing errors where they never did previously.
@ccstone@peternlewis - well I’m apparently one of those people who lives on the edge!
Before I discovered
I used to write fairly clunky macro sections to check for the folder’s existence. And I’m sure I only realised I could avoid doing the folder-exists check after reading about it somewhere here in the KM forum. So my vote is keep the action’s behaviour as-is because it is entirely reasonable.
BTW, this discussion went off-topic at around post #11; shouldn’t it be split off?
If it did error, all you would have to do is turn off the error and notification, so it would be better in general if it did. But as I say, I don't really want to change it. Potentially I could change it and grandfather in a turn off of notification and error. (EDIT: That would not work since there are other valid reasons for it to error that should not be automatically turned off).
This is probably not do-able -- but would it be possible to differentiate between a naked "Create Folder" and one in a "Try/Catch" block, keeping current behaviour for the first and throwing an error in the second?