Today I had another opportunity to play around with Microsoft Flow. What I wanted was – at least so I thought – fairly simple: When a list item is created in List A then create a new list item in List B and check – using a “Do Until” loop – at regular intervals whether this list item has been updated.
Microsoft Flow allows you to implement such a regular check with a “Do Until” block. Inside this block you can add an action and this action is basically the way for refreshing the data that will then be verified by the “Do Until” condition. So this is the first thing is important to remember: The data is not pulled in from the previous step but instead it is part of the “Do Until” block itself (which makes totally sense – but not at first sight). So in my case, I would create a new SharePoint list item with a “Create Item” action and then place another “Get Item” action inside the “Do Until” loop with the same site URL and list title and with the ID referencing the “Create Item” ID. Now the “Do Until” action can reference the list item fields from the “Get Item” action and things start to get working …
Count and Timeout
But not in my case things started to get working. Each time and again the “Do Until” loop completed in the blink of an eye, but without the condition being met. As it turns out, the “Do Until” loop tries and execute its number of retries that is defined by the “Count” limit as quickly as possible and if it is able to do so before the “Timeout” period expires, the “Do Until” loop simply finishes and the flow continues to the next step. So is “Does Until” your condition is met OR until the number of retries has been reached. In both cases, the loop will continue to the next step without an error. Only if one iteration of the loop runs longer than the defined Timeout an error will occur. So in my case I simply needed to do two things:
- Define a sensible combination of “Count”, “Timeout” and “Delay”
- Add a condition immediately after the “Do Until” block that validates for the very last time whether the condition is met to be able to decide how to proceed e.g. escalate because no timely response was received etc.
Count, Timeout and Delay
So it turns out to be important to understand how count and delay may interact. When count the absolute number of retries of the actions inside the “Do Until” loop is and you want for example to wait no longer than two days before you would end the loop then you could define a count of 48 and a delay of one hour. This would effectively then cause the flow to check each hour and verify its condition. After 48 times doing so, it would then continue (or of course sooner when the condition is met).