One of the common patterns we get asked about often is how to handle exceptions with a Logic App. If something fails during the flow, there are often exception policies or actions you want to make to correctly handle failures. This is a pattern we plan to make simpler and more powerful in the coming months, but you can follow these patterns today to catch exceptions.
First is to understand that every action within a Logic App flow has certain properties passed along with it. The most commonly accessed is @actions().outputs, where the outputs of the action are stored (e.g. the results of a SQL query). There are also more top-level attributes that are helpful in debugging and exception management. @actions().status (Succeeded, Failed, or Skipped), @actions().starttime (timestamp of when action started), and @actions().endtime (timestamp of when action completed) can all be useful.
The most common scenario is to create a log or a message whenever a failure occurs (this could be any action). At the end of your workflow you would add the step you want to be your "exception handler." In this instance I will say if a failure occurs, I want to add a message into a Service Bus Queue that will contain the status of each action within the workflow. I would add the Service Bus Queue action, and for the condition I would put:
@or(equals(actions('laststep').status, 'Failed'), equals(actions('laststep').status, 'Skipped'))
Where 'laststep' is the action ID for the last step in my workflow.
In simple terms, this condition is saying: "If the last step in my workflow fails, or if it was skipped (meaning something upstream failed), then execute this action."
We could then have the message to the queue be something like "Action 1: @{actions('step1').status}, Action 2: @{actions('step2').status}" and so on (where step1 and step2 are the action IDs of the steps in your workflow. That way if something fails, you'd have a message in a queue that you could read to find out where the failure occurred, and potentially take necessary actions. Not to mention you could expand on this to build a second Logic App that triggers whenever an item is added in the failure queue to execute a series of steps.
The one side-effect to this approach will be that in your run management blade, all runs will show as successful (even the ones that had a failure caught), because the exception was caught and handled. If you are using tooling that relies on the run status, or simply want the portal to show a flow as failed even if the exception was caught, the way to enable that would be add an action dependent on your exception action that will always fail (for example referencing a non-existing attribute like @actions().bogus). That way exceptions are caught and handled, but the overall status of the flow will still be "Failed"
Feel free to comment if you have any questions, and be sure to follow us or reach out to us on Twitter @logicappsio to stay in the loop on upcoming announcements and features.