Welcome once again to another Power Automate Best practices, Tips, and Tricks. In my previous blog posts, I talked about some of the most essential best practices you should have while working with the Power Automate:
And some tips and tricks:
- #4 Copy to my clipboard
- #5 Using Scopes
- #6 Error handling… configure run after settings
- #7 Delete notes
Today I’m going to speak about another critical Best practice, Tips, and Tricks that are often overlooked: learning from failures.
#8 Learn from failures
It is important for you from time to time to do an assessment of your existing Power Automate flows, especially when they failed. Not only analyze the business process to see what can be improved but you should also analyze the run history of our Power Automate and learn from the failures or mistakes that are happening.
Based on my long experience in Enterprise Integration, I can certainly say: Failure is critical! And we need to understand why is failing and address that issue so it doesn’t occur again.
And don’t be offended, we all make mistakes, and failures and errors will always exist, whether they are unplanned or not addressed in the initial requirements, a bug committed by the developer, or simply because certain external parts are offline or having problems. Here the idea is to be transparent, honest, concrete, bluntly trying to find those responsible or assign blame and really make our Power Automate flows more and more robust to errors or failures, progressively learning from failures. In a way as with aviation. Unfortunately, with each accident, aviation becomes safer because whenever this happens, a thorough analysis is carried out to discover the causes of the accident, and then new measures are applied so that this does not happen again.
If they found that a component without redundancy broke down for sure they will implement a rule forcing companies to add a secondary component to avoid this to happen again. The same can be applied to Power Automate, if a system is not always available we may need to implement a reentrant mechanism to handle these situations, if possible. For example, sending the message to a Sharepoint list to be processed later.
In some cases in traditional programming languages like C#, we call it defensive code:
Note: maybe this is not the best C# code but that is not the goal here.
In this case, when we try to read something from SQL Server, we don’t assume that the query brings always records, or at least we shouldn’t, we first see if there are any records to read, and only then do we try to read them.
So, why not apply the same principles and best practices to our Power Automate?
One time I was passing by in the hallway at DevScope for coffee and I noticed that one of my colleagues was working on a Logic App which is similar to Power Automate. Out of curiosity, I went to see what he was doing and after a few minutes, I asked him to show me. I immediately notice in the run history that from time to time the Logic App was failing so I ask him: why this is failing on a regular basis? He replies to me that “this is normal, there are no records on the SQL so it fails“! This is quite normal to see also happening in Power Automate flows. I even go further and say that it will occur more often inside Power Automate than Logic Apps:
Again, Failure is critical! If it is failing due to expected behavior, then you must redesign your business logic, so it doesn’t end up in a failure status!
And to fix this sample above is simple as adding a condition to check for example:
- If a particular field exists or contains a certain value:
- first(body(‘Exec_SP_-_GetLastExecutionTime’)?[‘resultsets’]?[‘Table1’])?[‘LastRun’]
- Or if the Table1 structure is empty
- empty(body(‘Exec_SP_-_GetLastExecutionTime’)?[‘resultsets’]?[‘Table1’])
This is just a simple case, but I think you got the point!
Stay tuned for the following Power Automate Best practices, Tips, and Tricks.
