Approval escalation, error handling, flow fails… why? how?

Introduction

An interesting pattern in Flow is what I call the escalation pattern: you ask someone to approve and if the approver doesn’t react on time, you escalate this approval to someone else.

There are different ways to implement this requirement, but you have to be very careful and to fully understand how error handling works in flow. I already discussed that in a previous post; you can also read Pieter Veenstra very good blog posts here and here.

But here I would like to illustrate a specific problem that you will probably face.

 

More details

You might be tempted to write this :

Where the scope is triggered when “Start an approval” does timeout :

To make it “testable”, you set the “Start an approval “action Timeout setting to 1 min :

However when you run this flow, after 1 minute the escalation will work, but the flow will fail :

The flow fails because the first action of left branch couldn’t work as expected. On the business point of view this does not make sense but if you think about how flow/logic apps is implemented…it does. Indeed the message associated with the Log Line Manager approved action on the left side is the following:

“ActionConditionFailed. The execution of template action ‘Log_Line_Manager_approved’ is skipped: the ‘runAfter’ condition for action ‘Start_an_approval’ is not satisfied. Expected status values ‘Succeeded’ and actual value ‘TimedOut’.”

You have different options :

Option 1.

the first one is to add a Terminate (with “Succeeded” status) in the right branch:

…and the flow succeeds:

And it succeeds even if you approve on time :

Option 2.

Another option is the add an action (here ” Compose do nothing”)  in the left branch in the second place (the first action of the left branch could be a scope) :

The run-at setting of this action should be:

 

This is because (as we saw it before) the Log Line Manager Approved action is skipped when we are running in a timeout:

End of course the second action of the left branch will run even if the right branch is waiting for approval as illustrated in the next picture :

So this works even though it is not very “citizen developer” (or business) friendly, to say the least.

Another reason in favor of NOT using the Terminate action is when we have subsequent actions that must run whatever branch is executed as illustrated here with the “Final Flow general logging action“:

 

Escalation and re-escalation

Now if you handle timeout in the first approval, you also have to handle it in the second approval.

Let’s define a flow variable hasbossReacted at the beginning of the flow and set it to false.

 

Let’s move the Boss approval request into a Do until loop :

The next picture illustrates the code inside the loop : we will ask the boss the approve or reject again and again until he reacts. The action “Ask big boss to approve” can also run into timeout; if the boss reacts, the next 2 action s(“Log Big Boss reacted” and “set variable didreact to true“) will run. They won’t  run if the approval does timeout. In case of timeout, only the action “set variable didreact to false” will run. So we can play with the error handling to do what we want to achieve :

Let’s test the 3 scenarios

 

1. The Line Manager reacts on time

2. The Line Manager does not react on time, but the big boss reacts on time

 

3. The Line Manager does not react on time and the big boss does not react on time

 

Not using a parallel branch

You can of course choose another way which is avoiding the parallel branch and working sequentially like this :

where “Escalate to Big Boss” handles the timeout error coming from “Start an approval” action and where “Log line manager reacted” is started if “Escalate to Big Boss” is skipped. I find the parallel branch brings more clarity because in the designer you see exactly what will run and when. For instance in the last picture it is not clear whether “Log Line Manager reacted” is an error handler to “Escalate to Big Boss” or to “start an approval”. You have to click on the setting to figure that out.

Conclusions

Error handling works well in Flow but it is a little bit tricky and you have to be very careful. We can use it to manage complex approval escalation cases, but  we need more out of box business functionalities bundled in the flow approval. This is currently way too complex for citizen development in my opinion. Escalation should not rely on system errors, this is too low level.

Also don’t forget that the code I demonstrated here cannot run beyond 30 days (the flow run and the approval stop after 30 days). If you need more than that, you have to implement my Flow controller pattern. Read my blog post and watch these videos 😦video 1, video 2 ).

 

Happy flowing !