Suppress Failure Notification on END_MANUALLY_CANCELLED workflow

[Bethel Ademowore]

I feel like this answer should be obvious to me, but I'm just not seeing it. We have a lot of workflows that we just cancel if the first FTP job doesn't have any files for pickup. Post processing looks like this:

Unfortunately, that status of manually cancelled kicks off a failure, which then opens a ticket that is not needed. Even if I were to cancel a workflow manually, I don't need a failure notification for it. 

Any ideas?

[Daryl Brown]

The way we've traditionally approached this type of thing is to have the polling job (be it an sftp download job or file event; same idea) trigger a separate workflow to process whatever files it sees, or even trigger a separate workflow for each file it sees.   (You might want/need to use a prep_process_report or prep_process_filename to figure out what files are present.)

This way, if the sftp job doesn't download anything, you don't kick off the file processing workflow to begin with, so no error notification gets generated.  (The sftp job itself might still reflect an error, but you could update that in the postconditions.)

[Joel Wiesmann]

Daryl proposed one potential solution. What would be an option as well is that the "checking-job" publishes an object variable (or write a record into a VARA object) that then controls the further processing. i.e. you might use precondition logic to inactivate the successor. In case that you have many successor tasks, best would be to put them in a workflow so you only need to place the inactivation-logic on one task.