Most actions don’t provide a response date for a good reason. We don’t need it. They run as fast as possible, and the difference between start and end time would be marginal. But some actions take time to respond because they are waiting for an action from the users, like the “Send an email with options,” for example. But even some of these won’t return a response date, which is a problem when we need it.
I will provide a simple solution that you can apply to any action or group of actions, but I want to show why it works and how we can take advantage of how Power Automate was built to get this information.
So, with this in mind, let’s start with the solution and then explore how Power Automate can help us get that information.
It’s pretty straightforward, but why does this work?
Why does it work?
If an action is connected to another, Power Automate will run them sequentially. Not only that, but Power Automate will only run one after the other on finishes. For example, in the case of the “Send an email with options,” it can be days without a response so that the Flow could be running for a while.
Since the Flow won’t start an action without another finishing (except for parallel tasks where both “paths” run simultaneously), we know that the following actions will wait for the one to finish, so if they wait for the previous action to complete (either with an error or not), the time they trigger is when the other one ends to use that to our advantage.
By fetching the date right after the action finishes, we know that the date will be the date the previous action spent (plus or minus a few milliseconds), so we have a stored date that we can use everywhere in the Flow.
Where can I use this?
You can use this in cases like:
- To store the date when the person answered a question.
- To know how much time a group of actions, included in a scope action, for example, took to execute on average.
- The time a Flow took to execute from start to finish. To do this, you can have a variable at the beginning of the Flow and another at the end and store both values.
The first one is more common since the users may take time to reply, but the other ones can be useful to improve your Flows, process, or anything in between where data is needed to make good decisions.
Storing the response time can be a massive plus to understanding inefficiencies in the system. Also, depending on where you store your data, you may not have the ability to store automatically, for example, the date of the record’s insert date. With this in mind, you need to keep the information on Power Automate and then save it to the system to have a history of the time it took for something to happen.
Finally, I want to highlight error handling. You can have a sequential task that fires only if your Flow is an error. In this case, it’s essential to know when the error occurred, so it’s pretty handy to have the date of the failure. You can use the same strategy and store the data so that you can have an additional datapoint to find what went wrong.
Like I always say, it’s all about strategy, and this is not the exception. You can get the information from your Flow, and, taking advantage of how Power Automate works, you can do some tasks that, although not supported in Flow, can be achieved nevertheless.