Handling ‘Run Flow’ failures from a business process flow

My previous post explored the Customer Voice side of digitising and application process. In these next few posts I will focus on how I leveraged specific parts of Power Automate to create a seamless process from application initiation, through to submission, follow up and beyond. There are two key Power Automate flows - one to send the application to the enquirer and one to receive the completed application from the customer.

This post will focus on handling flow run failures from a business process flow - gracefully and informatively in a user friendly manner!

Send

Sending the application is triggered from the business process flow after the enquirer has been to visit and would like to complete a digital application.

Get context of the record the ‘Run Flow’ button was called from

Use get record and ‘BPF Flow Stage Table Row ID’ to get the record which the flow button was called from - in this case the ‘Enquiry’

Error handling for customer email address

Unfortunately you cannot use business rules on the ‘Run Flow’ button on the business rpoces flow, so its entirely possible for a user to run the flow for an enquiry which doesn’t actually have an email address. This will cause errors and failures later in the flow so its best to handle this gracefully and to let the user know what went wrong/how to resolve it.

Mark business process flow step as failed

Use the ‘Update record’ to update the process Log linked to the ‘Flows Workflow Log Id’. Whether the flow fails or succeeds, if you don’t do this step the flow step will remain forever as ‘Processing’ which isn’t such a jolly user experience or audit trail.

Create an informative error email to calling user

As well as failing in the business process flow - we should notify the user as since the flow runs asynchronous (in the background) the failure message is not instant - they have probably left the record and carried on with their other tasks already. A few handy tips in this one -

• Sending an email to a non ‘Contact’ or ‘User’ aka an ‘unresolved recipient’ - in the case of the BPF Flow step the ‘ID’ it sends back for the calling user is actually the Azure Active Directory ID, not the Dataverse User ID. But you do also get the email of the user in the response - so we can use this to send the email to the ‘calling user’. More info on this one check out this blog post from Linn Zaw Winn

• Link the email back to the Enquiry using ‘Regarding’ - so that it will show on the activity timeline so if another user picks up the record later, they can clearly see what has happened, what went wrong and how to resolve the issue if not already done

• Create a Dynamics URL back to the record that works based on the environment the flow is deployed to using the urihost(), ‘BPF Flow Stage Table Row ID’ and <a href></a> HTML syntax to create a clickable link

URIHost -> uriHost(outputs('Get_Enquiry')?['body/@odata.id'])

<a href = "https://URIHost/main.aspx?pagetype=entityrecord&etn=TableLogicalName&id=RecordID">Link to Enquiry</a>

Send the email

Once the email is created use the ‘Perform a bound action’ action to trigger the email to send from Dataverse

What’s next?

We have handled any potential errors - my next post will focus on the ‘happy path’ and how to send the application to the customer in a way which is personalised, unique and trackable.