For Dynamics 365 System Admins

This blogpost will help you truly automate your Power Automate solution by handling any errors that crop up – but be careful!  You can easily build error handling into your flow that MASKS REAL ERRORS!  Read on, but first…

In our previous blog posts in this series, we reviewed:

– “Big Picture Power Automate Concepts for the D365 System Admin”
– “Power Automate Triggers for the D365 System Admin”
– “Power Automate ‘List Rows’
– “Power Automate ‘apply to each’ actions for the D365 System Admin”
– “Power Automate ‘Variables’ actions and common functions for the D365 System Admin”

These blog posts will certainly help you create your first Power Automate flow against D365 data.  If you aren’t familiar with Power Automate, they will help you get a basic handle on it.

Power Automate has built-in error handling at each step in the flow.  A common flow structure is to do a List Rows action followed by an “Apply to each” block.  You may not want to loop through the records returned by the List Rows action if there was some kind of problem running that query.

To modify the error handling, click the ellipsis menu on the step and select “Configure Run after”

That will require you to select the conditions under which this block will run, if a previous block has an issue.  The options are:

As you can see, ALL blocks are initially set up to only run if the preceding block was successful.  Checking the other boxes has effects as shown below:

– Has Failed.  If the preceding step fails, the flow will continue on like no failure occurred. Caution:  Setting error handling up like this can cause your flow to show “success” when in fact it died a horrible death.  USE WITH CAUTION when first starting out
– Is Skipped.  If a condition causes the block above to be skipped.
– Has Timed Out: the List Rows action did not complete; it timed out.

Advanced Error Handling

While Power Automate has error handling, beware the DANGERS of setting “Run after” settings. Flows can “succeed” even if there are MAJOR errors.

See this blog for a nice tutorial on setting up advanced error handling.

http://www.lifeonplanetgroove.com/advanced-error-handling-with-power-automate/

The key points from that blog:

[W]e can write Conditions that check the return status code and handle errors accordingly. The syntax for getting the HTTP Status Code in an Expression is like this:

1	outputs(‘your_action_name’).statusCode

Note that your action name needs to be in single quotes (not double!), and if you have spaces in your Action name (which most do), you’ll have to escape them with underscores instead.

A really nice pattern for error handling is to use a Switch action, and use the above formula in the “On” field. Click in this field, and click the Expression tab. Type this formula and click the OK button to insert your expression.

Then you can create a Case for each expected status code. For example,  Case ‘200’, you can then Update the item, Case ‘404’ create a new item, and Case ‘500’ terminate the workflow with an error message (because something unrecoverably bad probably happened).

Advanced: Azure Logic Apps

Flow has a rich set of actions, but sometimes users just need to do basic operations like getting the current time, adding numbers together, or replacing a part of a string of text. Starting today, that’s possible inline in any flow action. Microsoft Flow leverages the same Workflow Definition Language used by Azure Logic apps. For new users who are unfamiliar with the expression language, there is an inline help experience that shows how to use each expression as they build out their flow. To use an expression in your flow, first open the Add dynamic content menu.

From <https://flow.microsoft.com/en-us/blog/use-expressions-in-actions/>

The above Workflow Definition Language link:

https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-workflow-definition-language

Power Automate Quirks and Issues

While Power Automate is awesome, the user interface still needs some work.  There are some ‘quirks’ that may cause you some frustration.  Hopefully I’ve captured your issue, and the workaround or fix, in this section.

Action Step Labels Matter!

Power Automate unfortunately uses the LABEL of a step in, for example, expressions like “items()”.

Which means that your label cannot have special characters in it.  If you try to set an action step label to:

Set variable: Status to N/A

You’ll get an error that you can’t use “/” in the label name!

(This brings to mind constraints from long ago, when DOS filenames had to be 8.3.  This is embarrassing, IMO.)

Until you get the hang of the items() syntax, I recommend short label names, and if you are still having issues, try removing the spaces from the action step label. 

Debugging a Do Until loop Is a known issue.

The “run history” window is great for reviewing your flow and spotting issues.  Usually.  Unfortunately, if something fails inside of a loop, the “run history” window shows all of the blocks in that loop as grayed out, and you cannot get any information about the error.  Very annoying.

https://powerusers.microsoft.com/t5/Using-Flows/Troubleshooting-flow-Can-t-Expand-Loop/td-p/168820

My workaround: 

• – Document your existing Do Until structure (screenshot, variable formulas, dynamic variables, , e.g.) so you can rebuild it.
  – Drag key blocks (Insert/Update, e.g., and derivations for field values) up above the Do Until.
  (You will have to remove references to fields only available within the Do Until loop.)
  – Debug, yes, this will only work for one record
  – Copy the output and paste it into Notepad, or OneNote.
  – Examine that data to figure out what might be wrong.
  – Test, until one record perfect.
  – Rebuild the Do Until by dragging the blocks back into the Do Until loop area.

Debugging many records in a loop is a slow process

When you are reviewing a “run log”, and you have a List Rows action and an “Apply to each” action that loops through records, when you expand that step in the run log, you can see each of the records processed, and their values.  It’s a beautiful thing.  Unless you are trying to find the error that happened with record 87 of your loop…  They have “Next Record” and “Next Error” buttons, which help some. 

But it sure would be nice to have a “Last” and a “First” record button control when you review a flow? (And a LAST ERROR button, too!)

In the meantime, I typically use the “TOP” parameter in the “List Actions” action to reduce the rows that are processed by the flow.

You must tab outside of the field before hitting save or your change doesn’t take!!

Often you’ll need to fix minor syntax issues, like missing parens in a lookup field.  When you do so, you can make the change and save the flow.  However, I have found that if you don’t “TAB OUT” of the field first, your change may not be included when you save the flow.

Conclusion:

This blog series should help the Dynamics 365 System Administrator become competent in building Power Automate flows.  It described a common scenario: connect to the Dynamics 365 CRM Dataverse database; define a trigger to start the flow; and use List Rows and Apply to each actions to loop through an advanced find query and process rows differently using dynamics content and expressions.