You’re offline. This is a read only version of the page.
45
Hello everyone,
I have two identical flows:
Run Duration :
Number of actions:
This same flow when I was testing reached 25k actions, which throttled it down. As it was just a test, a few days later, I downloaded the solution, changed the flow IDs, and uploaded it again. Same issue: Flow A = 6min, Flow B = +16 hours;
If I am still under the limit, why is this scheduled flow taking so long to run? Why not both of them if the only change is the trigger?
I am the owner of the flow.
I have found a solution to my own problem:
My strategy was to create a child flow with the Schedule trigger and an action calling the child flow with the logic I wanted to be executed. It is not what I wanted, because I had to split the flow in two, but it worked as it should.
How to create and use a Child Flow:
Now create your main flow and add your trigger. In my case, I used the Recurrence Trigger. Also, add the action to call your child flow, and don't forget to reference the child flow inside the action.
Exactly, @Pstork1 . Weird behavior. I am working on a different flow to do the same job, but I am still not confident this would solve my issue. Even after assigning a new GUID to the flow, I was still being throttled for some reason. Limit? I doubt it. As you mentioned, it is the same context as only I would be running the flow.
You are correct that the Power Apps flow will run in the context of the person who is running Power apps. But in this case its the owner of the flow testing the app. So its the same person and the same context. When it goes into production that would account for the difference. But not when one person is writing everything and testing it.
@okeks is correct, unless in testing you are the one starting the flow in Power Apps. That is what I am assuming.
I don't see anything that would suggest why the recurrence flow is running so slow. Could it be that its running at a different time of day? In other words the Power Apps flow is running during working hours and the recurrence flow starts overnight.
But I do have a suggestion. One of the things that really slows down flows is using variables for storage in an Apply to Each loop. The problem is that every time you set the variable it needs to get a lock and that ruins any chance of using concurrency. I had a flow that ran 9+ hours with variables. When I switched it to Compose statements it dropped to 15 minutes.
@okeks Agreed. But the flow owner is me. When I run it by using the PowerApp trigger I am the user actioning the flow. For the automated version of the flow, I am the owner of it as well.
For other users, the manual version is also running in 6 min.
Hello @Pstork1 , thank you for your help.
I have three parallel Apply to Each action that takes 99% of the time for both flows.
- For Flow A (6min): All 6 minutes are on these three Apply to Each actions.
- For Flow B (+20 hours): All the hours spent also are on these three Apply to Each actions.
Unfortunately, after I deleted the solution and re-imported it with a new flow GUID, I lost the successful log.
This a sample of parallel main loops I created.
Goal:
- Import all excel files in another SharePoint dynamic folder structure and load them into their respective locations.
Example:
- Every day a new folder structure will be generated with this info (RegionABC/2022/04/12/02 **Hour**). Within this folder will have several excel files that are being imported.
Each Main Loop was balanced with similar workloads, so they pretty much finish at the same time.
The logic is the same, but the Duration is dramatically different.
I've read about concurrency control, but I am afraid to use it and the data be mixed in the process of getting content and creating a new file at the desired directory.
Answering your question, I own both flows, and all connections are on my account. The manual flow other people can run, but the time is the same (6 min). So the issue is not related to any other user.
The difference is that the PowerApps trigger uses the license of the user who actually triggered the flow and the Recurrence trigger uses the license of the flow owner.
Have you looked at sample runs from both flows? Each action will show how long that individual action took. Figuring out if the whole flow was slower or whether some specific action was causing a bottleneck will help. But I don't see anything in particular about a different trigger that should have that kind of effect. Is the flow running in the same person's security context each time?
@ScottShearer @Pstork1 Help! 😞
#1
WarrenBelz
146,635
Most Valuable Professional
#2
RandyHayes
76,287
Super User 2024 Season 1
#3
Pstork1
65,997
Most Valuable Professional
Share
Report
All responses (
Answers (
