Error handling triggers with transitory properties?

[jcoomans]

I've read through ALL of the responses about non-existent properties, but I can't seem to find a solution that works for me. My apologies in advance if this post is long. Here's a brief summary of my problem. . .

I have an automated Flow that is triggered by a connector. This connector subscribes to a web service that sends events to the flow. What I want to do is make sure that if that trigger gets an error response when it attempts to subscribe, I generate an error notification.

When the trigger is NOT successful, I get a JSON response with a property in the body called 'status' that gives me the error code. You can see an example of that here:

BUT, when the trigger is successful, that property is missing in the body. An example of a successful trigger is below:

If this subscription fails, I want to notify an email account, but I ALSO want to make sure that the flow shows up as "failed" in the flow list. To accomplish this, I created a parallel action for the notification. That way, the primary action will still fail, and the flow will show as failed in the list. Here's a image of the over Flow:

 

However, this parallel notification action is constantly failing when the trigger is successful, because the property 'status' does not exist. I've tried to change the expression triggerbody().status to one that looks for empty, but it still tells me the property doesn't exist. Is there an expression that I can use that will assign the variable to SOMETHING that the switch can evaluate?

[abm]

Hi @jcoomans 

Could you please try the following:

triggerBody()?['status']

Thanks

[jcoomans]

OK, changing from triggerbody().status to triggerbody()?['status'] allowed me to initialize the variable as a string. If the property doesn't exist, then I get an empty string. If it does exist, then I get the value.

Now I have a new problem. I am using a switch to do different notifications based on the value of that string. However, the switch and the case are showing errors. Here's a screenshot of the run:

And here's my actual flow:

I also tried using '401' in the case, but that didn't work either. It seems like the switch does not like evaluating cases by string values. What am I doing wrong?

[abm]

Hi @jcoomans 

Tested this 

Test Result

No single quotes I used. Not sure why its failing. Check the email connector mappings.

Thanks

[jcoomans]

OK, I finally figured out what is happening and why. In an effort to see more closely what was going on, I changed the flow so that I first initialize a variable, then parse the triggerbody() JSON response, and finally set the variable to the dynamic content from the parsing action.

What I discovered is that I missed that the value of the object ("status") is an integer in the JSON schema. There are no double quotes around the value 401. Therefore, I changed the type to Integer and retested. You can see the results below:

The only thing I don't understand is WHY flow didn't error out when I SET the variable to an integer when it was initialized as a string. I would have caught my error quicker. . .the issue was never really with the Switch. My mistake, but lots of time troubleshooting something that should have produced an error when I set the variable. 

[abm]

Hi @jcoomans 

Thanks for the update and good to hear that all working as expected now. 

If your problem has solved, please go ahead and mark the post as solved by clicking “Accept as Solution” so that this thread will be marked for other users to easily identify!

Thanks

[jcoomans]

Well, it's NOT working as expected. If the status field is empty, then I get an error every time because the Switch won't work with a null integer value. If I want a single Switch for all cases (empty, 200, 401, 403), then the variable MUST be a string, but Flow is automatically converting the ['status'] value to an integer EVERY TIME.

I even tried specifically identifying it as a string using string(triggerBody()?['status']), but Flow is automatically converting this to triggerBody()?['status'] again whenever I run the flow. This is infuriating. All I want to do is convert an integer that is either empty or has a number value to a string so that I can use one Switch for all cases. I mean, come one. This is one line of code in javascript.

I am becoming disillusioned very quickly.

[abm · Accepted solution]

Hi @jcoomans 

Thanks for your reply. You could use coalesce expression to overcome this. I don't want to give you an example as there is already a good post about this.

Have a look at this please.

https://sharepains.com/2018/05/29/microsoft-flow-improve-your-switches/

Thanks

Thanks

[jcoomans · Accepted solution]

OK, FINALLY, that did it. The coalesce expression is what I needed. Here is a look at the final result:

In simple terms, the coalesce function is looking in the trigger body for the 'status' key value pair, which is an Integer. If it is empty, then it substitutes the integer (notice no quotes) value of 0. The switch is now happy, because it is ONLY ever attempting to evaluate the result of an integer value. I'm telling you, if the JSON schema identifies something as an integer in a trigger, Flow absolutely will not let you redefine it as a string. I find this extremely annoying, but since I got this to work using integers, perhaps I can live with it.

By the way, if someone else is going to use this method to error handle non-existent properties, which is the cleanest I've seen so far, the make sure you do NOT make the mistake of trying to identify the actual 'value' of the key value pair. Why? Because coalesce only works if the top level object it is looking for is not found. So. . .if I use triggerbody()?['status'], then coalesce will return a null. BUT, if I use triggerbody()?['status']?'['value'], then coalesce will error out, because it was not able to query past 'status'. I get it, but this can easily frustrate you.

My suggestion to Microsoft. . .this shouldn't be that hard. JSON results in non-existent properties all the time. If I have a trigger node, having some built-in error handling options for non-existent properties would seem like a no-brainer. Especially for folks who aren't programmers.

[abm]

Hi @jcoomans 

Fantastic news and thanks for the update.

Thanks