Flow runs taking 8+ hours to take 'LIST A' submissions & update 'LIST B' - Help needed!!

[BigShotRob]

Okay, I've got a major issue with severe WF slowness and I've got to now swallow my pride and reach out to see if I can get some assistance, I cannot figure it out. Just for reference, I've built quite a bit with MS flow in the past 6-8 months, so I'm not "new" to flow (relatively speaking), but on that note, I don't really do much beyond out of the box components of flow, no custom calling or anything more on the developer background aspect of this, this is all pretty basic stuff.

Relevant Environmental Details:

I've got a business process that I've built on top of 3 lists, one of which is not included in any of the attached screenshots, because it's not the one that's CAUSING the slowness issue, but because I have one flow that's built from "List A" that takes submissions and updates "List B", it slows down this other Workflow because it also updates "List B", so when the other list's submissions get stuck in these big long queue's, it impacts this WF as well. In summary, 2 lists, each with one WF that updates the main list on a new item, updating no more than 5 columns each, simple.

The idea is to utilize "List B" as the 'only' list that users really need to interact with, these other 2 small lists just update it upon 'new item' submissions. I should mention, this whole process is a 1-2 time annual process, but there "COULD" be 50-150 submissions between the 2 small lists within a few hours every 6 months or so when entire departments are tasked with doing these particular business functions.

I have a unique field in the main "List B" that's a people picker, by design, every employee will have one line item that's associated with them. Each of the other 2 lists both have WF's that use the 'New Item' trigger, where they update the main list by using one 'GET ITEMS' and one condition to lookup to the list and update the line item where the employee name (Unique Field) is the same as the 'Created By' of each of these small lists ('List A' & 'List C'), there's really NOTHING that seems complex to me where this should be such an issue like it is. 

The Problem... 

As more line items have been created in the main list, the slower the workflow(s) go, at first I didn't think THAT much of it, but once we hit about 100 they were taking roughly 10 minutes per run, if 25 people submitted within 15 minutes, it was taking several HOURS to process these simple entries, which obviously does not work, for many reasons. Fast forward three days to today, the list is now approaching the 300 line item mark and I've got 10+ flow's in the queue that have been running 8 hours, who knows how long they'll take, have to figure this one out.

I've built many list flows that update other lists that have far more complex conditions, never had a problem like this. I thought it seemed like something's bugged or glitchy, I re-created the WF from scratch just in case, same problem.

In screenshot #1, you'll see the main workflow that's experiencing the problems, a trigger on new item creation, a 'gets items' to retreive the items from 'List B', looks for the ONE line item that has a name field that matches the current items, created by "Display name" field, once it finds that item, it runs through a series of 5-7 conditions on that particular line item, to determine which columns it should update.

The issue though from what I'm seeing when I look at these flow runs (Shown in screenshot #3), is that the 'get items' retrieval 'apply to each' condition takes WAY TOO LONG to determine if that the source and destination columns don't line up, and move to the next item to see if that one lines up, I actually clicked through 300 of these one by one just to see the times associated with each of the FALSE RESULTS that one item takes, that to me should not be something that ever takes more than 1s to process, there's not multiple conditions, just one, name field (List A) -> lookup name field (List B), only one item should evaluate to TRUE.

That being said, when I clicked through all of them, I noticed SEVERAL had condition times of MANY minutes, just to determine that the expression evaluates to "false", which doesn't make sense. Also, they are never identical either, some take 4m, some take 8, some take 27 seconds, most come through in 0s or 1s (as they should), but every 10 or so, something's taking multiple minutes, there lies the problem, I just CANNOT figure out WHY that is, any ideas welcome, I'm all out. In a perfect world, we'd be able to take MS's back end performance logs and sift through them to analyze why it's getting so hung up on seemingly simple expressions, but obviously we only get limited workflow insight to diagnose performance issues like this one so I'm just at a loss.

I've also edited the settings on the 'Get Items' to do pagination so I could override the get items max from 100 to 900, so I know we'll never have capacity issues there, but this problem existed well before I did that so that's not the cause. I've also tried stopping all the flow runs in the 'queue' so I could try processing one at a time, still the same problem, so it seems entirely unrelated to the volume that get submitted to the list at a specific time, because I can go in there right now when nobody is in the system and create one entry, takes forever, why is that?

See attached screens, screenshot #1 is of the slow WF, Screen #2 is expanding the condition, but the problem isn't in there, but I thought I'd provide that just in case.

Hopefully someone can assist, I know this is long, thanks in advance.

[v-xida-msft]

Hi @BigShotRob,

How many records existed in your SharePoint LIST B and LIST A?

Could you please share a bit more about your SharePoint LIST B and LIST A?

Further, which license does your Microsoft Flow belong to?

According to the screenshot that you provided, there are hundreds of records existed in your SharePoint LIST B, is it true? The amount of records existed in your LIST B would take effect on the run time of your flow. Please consider take a try to reduce the amount of records existed in your LIST B and run the flow again to check if the issue is improved.

Different licenses of Microsoft Flow would have a different flow frequency. More details about Maximum flow frequency of different license of Microsoft Flow, please check the following article:

https://preview.flow.microsoft.com/en-us/pricing/

In addition, the flow would have its own trigger interval. There is a limit in run duration of a single flow run, the max run duration is 30 days. More details about limits in Run duration and retention, please check the following article:

Limits of run duration and retention

Best regards,

Kris