I'm getting inconsistencies with persistence of variable data in recursions using both Flow and Cross-Flow types.
My goal is to increment several data points from recursion to recursion, so I may present a summary of the total number of devices reviewed and edited. I setup the script to clear all flow and cross-flow variables on the first run and then set a start time and zero out others. I've confirmed the correct settings on the first run of the script, but the remaining recursions flip back and forth between the currently running flow and prior completed flows.
The image below shows:
- First image: Start of flow (1st recursion) setting the start time.
- Second image: A get of the variable at the end of the 1st recursion confirming it was set properly.
- Third image: The second run of the recursion referencing a completed prior run ~9 mins earlier.
- Fourth image: The value of the start time saved in the ~9m earlier completed run.
Am I using the wrong type of persistent variable? Been trying everything on my own for a few weeks now.
1 ACCEPTED SOLUTION
Hi @MHScott, great question.
Persist Data writes at the end of an execution. When you invoke a recursive trigger, the next execution starts before the current one finishes, so the persisted data hasn’t been saved yet. That’s why iteration 2 often sees stale data, but iteration 3 and onward usually works (by then, iteration 1 has completed and its data is available).
Instead of using Persist Data, you can pass your variables directly in the recursive trigger’s cursor field and then read them with the Get Recursive Cursor action. In the first iteration, you can set the default cursor value to 0 and add a branch to create your first object. After that, you can embed your variables inside the cursor object and add as many as you need as key‑value pairs. I’m including an example in the screenshots below.
Let me know if that helps.
Hi @MHScott, great question.
Persist Data writes at the end of an execution. When you invoke a recursive trigger, the next execution starts before the current one finishes, so the persisted data hasn’t been saved yet. That’s why iteration 2 often sees stale data, but iteration 3 and onward usually works (by then, iteration 1 has completed and its data is available).
Instead of using Persist Data, you can pass your variables directly in the recursive trigger’s cursor field and then read them with the Get Recursive Cursor action. In the first iteration, you can set the default cursor value to 0 and add a branch to create your first object. After that, you can embed your variables inside the cursor object and add as many as you need as key‑value pairs. I’m including an example in the screenshots below.
Let me know if that helps.
