POWER AUTOMATE DESKTOP TAKES SEVERAL MINUTES TO DOWNLOAD FLOWS - ALL MY FLOWS ARE TIMING OUT BECAUSE THE INITIAL DOWNLOAD TAKES SO LONG!

[HEATFreight]

I have PAD flows which have not been changed or edited for over a week now, yet PAD always re-downloads the queued flow before every single run! I have just updated to the latest version of PAD, which seems to deprecate the gateway connection in favor of the new "machine" connection. I was already using the machine connection but had yet to uninstall the gateway. So I uninstalled the gateway and updated to newest PAD release, yet the performance is just as bad as before I updated.

Before today the download of a PAD flow typically did not take more than 30 seconds to 1 minute. Now it takes 2 or 3 minutes minimum. I have fast internet! (.5 gbps) I would expect to get better performance after upgrading and whatnot, but it's so sluggish it's unusable now.

Why does PAD re-download each flow every time before running it anyway? Why can't PAD cache my flows locally? NOTHING HAS CHANGED! If the flow is unedited, why are we downloading it again every time it runs?!??!?!?!

This download lag we are experiencing recently makes attended RPA completely useless. WTF Microsoft! Figure this out please. I honestly don't know why anyone would pay for this crappy service, what a scam!

[HEATFreight]

Update: maybe it's getting better or returning to normal? Tested a flow and it worked. Still not impressed with how long PAD takes to "download" a flow that has not been edited... What happens is the cloud flow that triggers my PAD flow times out. The Run a Desktop Flow action has to have a relatively short timeout or there could be a cascade of failed flows if one of them gets stuck. When the service is degraded, slow flow-downloads cause time outs. Very big problem!

[HEATFreight]

Ughhhh! This. Is. Still. Happening.

Wtf Microsoft! Please get your act together. There's absolutely no good reason my cloud-triggered desktop flows should be failing to run. Normally it takes an absurd 2 or 3 minutes to "download" the desktop flow or whatever Microsoft is doing while the flow is queued but inexplicably not running yet. But on some days that 2 or 3 minutes turns into 4 or 5 and then my flow times out. Extending the timeout is not an option because it would take longer to find out that it's not going to run at all, so the timeout should be set for the average amount of time the flow takes to run plus some buffer time. When Microsoft is not sh!tting the bed, this works fine. In fact, I don't think the flows are able to run at all when this issue is happening. It has nothing to do with the timeout per se. Flows without a timeout would seemingly not run at all. The green icon that shows a flow is queued is present, yet flow never initiates. Worked fine yesterday. Nothing has changed.

What. The. F@@ck. Microsoft?!?!?!?

Please fix this. Why in the world should we keep paying for this crap? Very frustrating. Not effing worth the money we pay. Considering scrapping this and finding something that works.

You guys are clowns, straight up.

[HEATFreight · Accepted solution]

There is a chance that inadequate RAM allocated to the Hyper-V virtual machine that runs our PAD flows was the root cause of these intermittent issues. We've doubled the RAM for that VM. Hoping that fixes it.

[ccrohlman]

We are experiencing the some issue with some flows. How much RAM did you end up allocating to the VM?

[HEATFreight]

I recall using 16GB of RAM per VM (one dev "machine" and one prod "machine").

This got me to presumably the best possible run time for my PAD flow (i.e. no longer resource constrained), but it's still a really slow service. Not a fan of PAD! The run time is fast (my PAD flow just runs a script), but the call time and response time are slow. It takes a long time to call up a PAD flow and a long time for a completed PAD flow to respond back to Power Automate, and for this reason PAD flows are not a production quality service. I highly recommend you abandon them ASAP.

We completely eliminated PAD flows from our process and moved all that functionality to an Azure Function App + Custom Connector and it runs a million times faster.

[carlos_slim]

Cannot understand why PAD does not cache a process and checks if it has been changed before it downloads. I understand the concept of the cloud, but like a lot of users are experiencing: this is just not working. Years have passed since the acquisition of WinAutomation and it is still my preferred application because of this. I am so happy I bought the perpetual license years ago..