Need an easy way to know how errors fit into the 'run after' categories.

[younceb]

Hi,

I want to handle errors from the 'Run a flow built with Power Automate for desktop' in different wants based on the error or based on the error category, ie, those as defined by 'run after' options. Is there any easy way to know which category the error falls into:

1. Timeout

2. Skipped

3. Failed

4. Success (should be pretty easy to tell)

[Agnius]

This post is related more to cloud flows and as such, I will move it to the appropriate forums for cloud flows.

As to your question, if your flow returns an error, the action will fail and as such, it will fall under the "Failed" category.

It is "Skipped" when the action never runs due to some rules/conditions. It falls under "Timeout" if the flow is queued and stays so for too long and then gets cancelled due to a time limit for how long it can stay in the queue (3 hours usually).

-------------------------------------------------------------------------

If I have answered your question, please mark it as the preferred solution. If you like my response, please give it a Thumbs Up.

I also provide paid consultancy and development services using Power Automate. If you're interested, DM me and we can discuss it.

[wskinnermctc]

I'm not very familiar with PA Desktop, but I would think about the errors like this

Success - Obviously

Skipped - Nothing to do - the previous action did not run at all because it had nothing to do. Example of an Apply to Each that has no items will just get skipped. 

Timeout - Couldn't connect - the connection between power automate and the source had some problem with getting data or amount of calls allowed.

Fail - Flow action broken - the previous action attempted to run but didn't work. So lets say the action did get the data, but an expression was wrong, this step will fail.

I'm not familiar with power automate desktop, but I guess one way to test this would be to intentionally create errors in the desktop flow. Then run the cloud flow and see what the result will be. 

[EmadBeshai]

Hi @younceb,

You can achieve that by running a parallel branches and inside each branch you can configure the run after, by this way you will be able to know which which status that will  trigger your steps.
Here you can find more about parallel branchs Power Automate Parallel Branch with Examples - SPGuides

 Please do as shown below:

If this post helps you with your problem, please mark this answer as Accepted Solution.
If you like my response, please give it a Thumbs Up.

[Agnius]

This is not related to PAD, and that is why I moved the topic to this forum. The "configure run after" is a thing specific to cloud flows and works the same way regardless of the action in question. Hence my reply on how it works.

[EmadBeshai]

Hi @younceb ,

If you found this solution helpful please mark the answer as accepted solution to help others to find the correct support.

Thank you!

[younceb]

I understand about parallel branches, and it would be the solution for handling errors of different types. My question comes in based on knowing for sure which error category it falls into. Skipped is likely more obvious, however there could be some overlap with timeout and failure.

Apologies about placing this in the wrong forum, I was justifying this based on errors specifically coming from this connector which would be unique from errors coming from other connectors.

An error for example that I would want an error response to be different between the two:

Error (1) Error at index: 8 with name: Stop flow at line number: Subflow: LoadConfig, Action: 8, Action name: Stop flow in subflow: LoadConfig -- -- Configuration file does not exist as expected at: [path]

Error (2) 

 
"The run has exceeded the queue waiting time limit. Consider allocating more machines or spreading desktop flow runs to optimize wait time in the queue. " that returns with "Bad Request". 
***I would argue that a response of Bad Request is not a clear indication of 'timeout'. Testing this is a bit of pain as I would need something to stay in queue for several hours

In either error scenario, the desired following actions could be different

[Agnius · Accepted solution]

The timeout for the queue is actually an error and falls under "Failed". If you want to have different actions taken for that, you will need to parse the output of the error and have a condition. The default error body for a queue timeout will be as follows:

"body": {
        "error": {
            "code": "NoCandidateMachine",
            "message": "The run has exceeded the queue waiting time limit. Consider allocating more machines or spreading desktop flow runs to optimize wait time in the queue. "
        }
}

You can use the actions() expression to get the output. So, you can do a Parse JSON action on actions('Run_a_flow_built_with_Power_Automate_for_desktop')  (assuming you have not renamed the action) and provide the sample to generate the schema. And then if the error code is "NoCandidateMachine", you can use some specific actions.

Note that "NoCandidateMachine" can also be thrown if you run attended flows and there is no active user session on the machine. But the body in that case will actually be different and look like this:

"body": {
        "error": {
            "details": [
                {
                    "code": "NoUnlockedActiveSessionForAttended",
                    "target": "{MachineName}",
                    "message": "No unlocked user sessions found on the target machine. Cannot execute attended desktop flow."
                }
            ],
            "code": "NoCandidateMachine",
            "message": "No machine able to run the desktop flow has been found. Aborting execution. Error encountered when connecting to machines: No unlocked user sessions found on the target machine. Cannot execute attended desktop flow. ({MachineName})"
        }
}

So, you might want to actually use the message itself in your condition.

-------------------------------------------------------------------------
If I have answered your question, please mark it as the preferred solution. If you like my response, please give it a Thumbs Up.

I also provide paid consultancy and development services using Power Automate. If you're interested, DM me and we can discuss it.

[younceb]

Understood, and parsing the error message is where I landed yesterday. I suppose my remaining question is how did you know for sure that these above error messages fell into the 'Failed' category? Did you have to rely on testing?

[Agnius]

Yeah, I had a client where this had happened a few weeks ago, so I just pulled up the logs from their flows. Not sure if there is a way to be sure about that without actually running a test.