We are using the default Export task from the out-of-the-box Task Add-in in PDM to export DXF files from our drawings of sheet metal parts.  Our company standard is that a drawing of a sheet metal part will include a sheet with the flat pattern, which is saved out to DXF for our nesting team.

I can set up the export task to make use of this with the following settings (we just need to make sure our flat pattern sheets have 'FLAT' in the name), and the export task does its job: 

However, for our drawings that do NOT contain flat patterns (all of our assemblies and all parts that aren't sheet/plate), they wouldn't contain a sheet with 'FLAT' in the name, and no DXF would (or should) be saved.  The export task, written as-is, marks this as a 'Failure' and provide a log file with the message "Document [filename] didn't contain any sheets named 'FLAT'".

I can go into the script for the task (Task properties → Output File Details → Advanced Scripting Options) and comment out the specific LOG command that creates that error message (or even insert a command to end the macro instead of creating the log entry), and this will eliminate the log file from the error, but the Task will still be marked as a failure with a "No file converted" error message:

In my opinion, this is a misuse of marking the task as a failure.

It's one thing to mark a task a failure because you've logged an error.  But if no error is logged, should the task be marking it as a failure?

It'd be nice to not have error reports on things that aren't errors (false negatives like this are, in my opinion, hurting the credibility of PDM early in our implementation), and I would argue there's a clear difference between "not saving a file because we had no eligible sheets in our file" and "not saving a file because ModelDocExt::SaveAs failed or no file existed despite that function returning TRUE".

The only things I can think of to work around this would be to (a) execute the task manually (not on a workflow transition), or (b) require my users to manually flag data cards of drawings with flat patterns with a checkbox control linked to a variable, then introduce duplicate versions of our release transitions with conditions built on that variable, since the only condition we can put on an Execute Task action in a workflow transition is the file extension.