Trigger a retry on failure

Hi all,

I have a suite of processes that run each morning but are designed to fail if their inputs have not been updated that day (by an earlier process). These then need to be run manually once the inputs are ready.

What I’d like is to be able to schedule the job to run again later (say an hour) on the first couple of failures (so after three attempts it doesn’t schedule). I’d prefer to be able to do this within orchestrator, but if it can be done within a project then I’d be happy to hear about it.

Is this possible?


Hi @SoqedHozi ,

Hope you are doing well.

You can use Global Exception Handler to serve the purpose that you mentioned above. Please find the detailed description below.

Mark this as solution if this helps you.:slight_smile:

But what activity would I use? Note that I am not using queues here so cannot use postpose.

Have your automation write out a text file named with today’s date when it succeeds. Then just schedule it to run 4 times a day. Write the automation to check if the file exists (meaning an earlier run already succeeded) and if the file is there do nothing and just end.

1 Like

Hi @SoqedHozi,

Please right-click on the main workflow XAML. It will give you the option to enable “Global exception Handler”.

You don’t need queues to enable this. :slight_smile:

I think you’re missing the point.

The process will throw an error (by design) if the input file is not from today. Therefore on failure the process must reschedule in orchestrator. The global handler will not do this unless you can tell me, as per my original question, of an activity that will do this.


Quite like this as an approach, but it would throw success/fail rates off a bit! If there’s no other way and manual processing if too much of an issue I’ll certainly try this.

It doesn’t have to throw anything off. You could just have it fail (Terminate Workflow activity) if the file is already there.

Thank you. This is a really good idea. I have several workflows that are using reports generated by a system and sometimes that que gets bogged down and doesn’t generate the reports in the usual timeframe. This approach would fix my issue of manually triggering them again once the reports finally show up. This is a better approach than what I had been thinking of doing.