Prevent Bad Data In Your Power Automate Loops
In a client’s production environment, a flow processing thousands of records was outputting incorrect data. The GUID of one record was being referenced by another when it shouldn’t have – how could we have data in one instance of an “Apply to each” show up in another?
The error was found to be a “Set variable” action inside an “Apply to each” loop with concurrency control turned on. We were running as many records through our processes as we could so the flow would run faster. Well, it ran too fast and was changing the variable before the previous loop was referencing it.
To make a Power Platform comparison, consider each iteration of an “Apply to each” to be a page in a Power App. When a variable is changed inside an “Apply to each” in Power Automate, they behave more like Global Variables in Power Apps than like Context Variables.
- Global Variables – Changing a variable on one screen of a Power App changes the value on all screens of an app.
- Context Variables – The value of the variable is specific to the screen is set on. If it is changed on another screen, it is not affected on the others (by default).
How does your workplace measure up?
Answer 20 simple questions to get a tailored report for your office across 6 key focus areas.
Do Not Change Variables Inside “Apply to Each” Actions with Concurrency Control Turned On.
When your loops are running simultaneously, the variable that you are setting could change prior to being used later in the same iteration. What is set in one loop, might end up in another.
In our experience, we found this small error impacted multiple rows of data in a client’s production environment – a worst-case situation for many developers. This was not caught in our test environment because the quantity of data was significantly smaller and the risk of bleed-over was much lower.
To avoid putting data at risk of becoming contaminated, you have a couple options:
1. Keep Concurrency Control Turned Off
This prevents your loops from running simultaneously. If they run one-at-a-time, you won’t be updating your next variable until the iteration has finished.
By default, this setting is turned off on every new “Apply to each” action; if you haven’t turned it on, your variables should be secure. To view these settings, click the ellipses (…) on the top right of the “Apply to each” action and click “Settings.” Toggling concurrency control off will prevent multiple loops from running at the same time.
2. Do Not Increment, Append, or Set Variables In Your “Apply to Each” Actions
If your flows are processing a large amount of data and taking too long to complete, maybe concurrency control is necessary for you. In this case, it’s best to keep variables out.
My personal preference is to avoid variables in my flows unless necessary. If I’m only setting a particular variable once in my flow, I’ll use a “Compose” action instead.
- One reason I prefer this is because variables can only be initialized at the top level of a flow. If you’re setting it within a container like “Scope” or “Condition,” you’ll need two actions to complete the job: “Initialize variable” on the top level and “Set variable” within your “Scope.” Why do twice what you only need to do once?
- Compose actions within an “Apply to each” exist within the context of their own iteration. If the output is being used inside the same loop its value is specific to its iteration (like a context variable on a Power Apps page 👀)
Conclusion
It’s simple to avoid creating this bug once you’re aware of the potential dangers of changing variable values inside “Apply to each” actions. The most challenging part for us was determining the source of our problem. Now we know, changing variables and concurrent loops just don’t mix.
%20copy.jpg)
