Extremely Slow

[Delid4ve]

Is anyone else finding flow slow to use..

It akes around a minute to expand any action or condition, another minute to populate dynamic content, making it extremely tiresome to edit, test and update. 

[v-xida-msft]

Hi @Delid4ve,

I make a test on my side and it expands quickly.

Please check if your network is in a good condition, the connection would affect the loading speed.

Best regards,

Kris

[Delid4ve]

I monitored yesterday.

Flow has 5 conditions, about 40 actions icluding SQL,ODFB, Sharepoint and data operations.

On checking system resources chrome was using over 40% CPU and over 600MB memory.  Connection is fine, Leased Line 40mb/s Fibre to the premesis. (i5 cpu, 8gb ram)

Internet explorer and the flow mobile app could not even load the flow, just timeout errors.

I have had to split the flow into 2 flows in order to edit, however its still very slow.

It seems to slow down as soon as you have more than 2 conditions nested.  The flow executes and completes fine in around 12 seconds, so im assuming its just the JAVA frame used for editing that is eating resources.

[katonage]

I've experienced similar thing.
For me it is very slow to load the first time. Better leave it there for minutes. Once you managed to edit it, save, see flow immediate run and go back to edit is relatively fast. There are problems with text boxes too.

[Mike2500]

This is a commonly reported issue. The docs say Flow has a max of 250 actions, but performance problems show up with a few dozen. Here's a similar post where the advice was to break flows into multiple flows when there were 50+ actions, with a member of the support team saying they hadn't experienced Flows with 20+ items. Though, the process for creating nested flows is a bit challenging, and involves more of a developer skill-set than what many power users would be comfortable with.

Perhaps the official MS guidance would be to switch over to a Logic app or to call Azure functions for these more complicated scenarios.

[katonage]

@ the member of the support team

You 've created a 'programming language' which shouldnt fail ath the second action. You should work on making this usable for larger codes. See my architecture with 20+ actions broken into 3 parts (not because of size, but because of current limitations: sharing and nested for each). The main theread opens in minutes on desktop. I also had to use multiple workarounds (e.g. get group memebrs by group name, convert to pdf) that extended the number of actions significantly.

For the middle level users it would be interesting to create action with a large text block, where user could type its code - but still shouldnt bother with credentials and connectors.

[Mupps]

Thanks @Mike2500 for linking to the other post.

I've expressed my frustration there!

[Cologne_Claret]

I am finding it very annoying too.

I have a flow with a switch having 3 conditions. Each condition has a further sub-condition and each sub-condition has a sub-condition in which I filter and then read a Sharepoint list of 250 users, grab their email addresses, concatenate to an array and add the resulting array to another list.

The flow runs in about 1 minute if I only run through this loop for one input list entry. If I run for a list holding 350 different combinations of each of the above conditions then 5-6 hours!!!

In addition, whenever I open the flow to edit my laptop fan goes into overdrive and I have 50% CPU utilization of Internet Explorer. I sometimes have to wait a minute or more before I can click on any of the objects in the flow, and then another minute or so before I can edit.

I work in the IT department of a large corporation, testing O365 and Flow, and at present could not recommend this product to our users, other than to add 3 or 4 objects to a flow.

😞

[Anonymous]

This issue goes back and forth from being quick or mildly annoying - to being virtually useless.

Guess which it is right now?  Unable to edit my flows without waiting MINUTES whenever I click on an object for it to open.  

Doesn't matter which browser - Edge, Chrome, or Firefox...

[slyuso]

I would like to add my 2 cents.

I refactored Nintex workflow that updates a list with values from .csv file.

On prem, the Nintex workflow runs about 8 minutes. The run time depends how many items need to be updated.
If running 2 times sequentially, no items are updated. This "check" run runs for about 3 minutes.
The list has about 2000 items.

The algorithm is prety simple: Read all existing items in the list.
Then, for every line in the .csv file:
- split the line
- find in and item with ID column exists.
    if the second column is different from retreived value in the list, update

If does not, create a new item

Logic is the same in Nintex and Flow. 

Flow.
My initial design produced a Flow that runs for about 6 hours for "check" run (that is, without updates).
Then, made modifications and used different data manipulations (Compose vs. variables, select, etc.)
As a result, the Flow still runs for 3.5 hours without updates and about 4 hours with 25% new or updated items.

Obviously, the Flows are so inefficient. 

[abpmr_entarc]

UPDATE: I submited a MS support ticket on this matter. Infinite "Loading..." loop for all of my flows, in a state of both on or off.

This platform has been the answer to many of the issues in our organization. But, the lag in bahvior is wildly inconsistent and cannot be trusted to perform when it really matters. C'mon Microsoft, speed this up. The "flow is too compliated" crap doesn't hold water - the flows are no more or less intricate than what the underlying code already understands. I also realize everything-MS is constantly evolving, so when I see slowness I am hopeful that something new is being published in the background that will improve the platform.

Flow is powerful tool for the masses who are either not developers, whose primary role isn't coding, or to meet a need that can be accomplished more quickly than would a new Visual Studio project. Flow is a production tool that behaves like a buggy new app in its first build.

[Anonymous]

I have a Flow with 7 Switch conditions. Each condition has several nested conditions and apply-to-each loops. Once I got all the tedious actions in place, I now find it's virtually un-editable. It just freezes constantly. Actions are agonizingly slow to open. I'm pretty much stuck. It RUNS, but I cannot EDIT it. Do I need to restructure the whole thing with child flows? Or is there some configuration I need to tweak that will make this usable?

[Mike2500]

Unfortunately, the answer might be child flows, as painful as that is. Another suggestion is to try a different browser, and also try it with a better laptop. Yes, really. You may get a significant performance boost using a newer, faster laptop/machine, which is kind of crazy, as this means someone can create a flow that their coworkers can't easily edit, based on their machine specs.

If you have an older laptop and don't have anything newer to test, spin up a decent VM in azure and edit the flow from that VM. Before I upgraded my laptop, that's how I edited complex flows and Power Apps forms, due to to the significant performance difference between my older laptop and the Azure VM. (if you don't have access to azure, search for "azure dev essentials" for a free program from MS that provides a certain amount of free credits to try).  

[Anonymous]

I just wanted to let everyone know that I did end up rebuilding all my switches as child flows -- which worked but was time-consuming, kind of complicated, and introduced it's own problems. Ultimately, I ended up rebuilding a third time -- with completely independent Flows that run based on specific trigger conditions. Trigger conditions are a life-saver! Also, once I got the whole thing built, I could easily Save As... and make a copy of the Flow (6 more times), which is a huge benefit that you can't do with a child flow. Once copies were made, I had to change the trigger conditions - of course - and a few other configurations. But overall it was a much better way to do things. 

You can do multiple conditions (defaults to AND), but for this project, mine were simple. Just based on a choice column value, for example:

@equals(triggerBody()?['Segment']?['value'],'Site Services')

For reference:

Trigger based on choice column value 

Trigger Conditions 

After this, I really recommend that if you're looking at a bunch of potential Switch statements, consider distinct Flows with trigger conditions instead. Easier to build and maintain. Faster, simpler, less need to diligently rename each repeated action. I had a consistent naming convention and I also bundled everything into a Solution, so that anyone looking at this after me knows that they belong together.

[GJones]

What would be the pricing implications of splitting into child flows? 

Wouldn't that mean you are paying multiple times (per flow) for complex automations?

[michaelt1998]

I also experience this issue. I hate this product with all my heart but I have to use it to support my orgs existing infrastructure. MS please get it together

[VictorIvanidze]

Could you describe the problem in details? 

[reisha4321]

I already am using child flows and it's still slow.  Any updates or resolutation for this?

[GJones]

I suspect the only other solution is to have less fields in your tables.  

[sami_mrs]

Yes my fellow. I am experiencing the as you said. Even after changing many things

and save it, but automatically deleted edited parameters. It is really testing my temper.