I am trying to set up a Do Until loop in a Flow. Basically I want to wait until a field in my SP list = a certain value. I have my Do Until count set to 5 (for testing purposes) and the action inside of my loop is to Delay 20 minutes. So, in theory this should run 5 times for 20 minutes each before it finishes and continues on with the other steps in the flow. My problem is that it runs one time (one 20 minute wait) and then jumps out of the Do Until loop and the SP list item hasn't changed. Am I missing something? The flow is running when a new item is added to the SP list. Do I need to do a Get Items or something for this scenario to work? Thanks.
Thanks for the info and I guess that the "Get Item" should be the key change. Wish I had thought of that and not assumed that the Do until would autmatically re-assess.
I tried this again using a Single line of text field.
Condition: EngIsAssigned equal to Yes | Also tried EngIsAssigned contains Yes
I still get 3 emails. (My count limit)
I tried creating the new item with EngIsAssigned set to No, wait for first email, set to Yes.
I even tried creating the new item and setting the EngIsAssigned field to Yes from the start. Still get 3 emails?
Frustratingly, when i look at the flow history after (or even while it is running) the Get Item clearly shows the EngIsAssigned as Yes.
Get Item Output while running:
Russell, I feel your pain. I've spent too much time trying to get the Do Until to work how I wanted. Try Do Until Not Equal to No
I've had much more success with the Not Equal condition than the others. Also, make sure you are referencing the EngIsAssigned item from the most recent Get Item action.
If that doesn't work, I highly suggest submitting a ticket with Microsoft. They told me that I was the first one to submit a Do Until ticket saying it didn't work, so they are considering it resolved at this point.
That finally did it. I must admit that i didn't expect there to be a separately instantiated data set from the Get and it was a little weird in my head to think that i can reference it before it executes, but I just need to change the way i think about this and it ultimately makes sense if not intuative. I can certainly see the value in having a "was" and an "is now" version of the list item! When i used SPD workflows, there were many times when I wished i could have both sets of data. I recall creating many additional fields just to store the previous value that was in a field that I needed to take action from. I'm going to have to go back through old projects and figure out what new options this opens up because I think there are many!
In short the winning combination was:
1. Add a Get after the wait period to get an updated data set from your list item
2. Make sure the dynamic content selected in the Do until condition is specifically from the Get data not the original list (so you have to add your get action BEFORE you add the condition to the Do until)
3. I did use the Do until not equal to option but now that I understand the logic, i'm sure other conditions should work... but hey, my colleague and i always joke that getting sharepoint workflows to do what you want is like this conversation:
Me: Do this
Me: Deletes "Do This"... Do This
Me: Deletes "Do This"... Do This
SharePoint: Oh alright! There!! I did it!
Thanks for your help!
Russell, Can you share a screenshot of your updated, working flow? I'm trying to follow the conversation here but got lost somewhere along the way. Bug or no bug, this doesn't seem like the ideal approach to the DoUntil feature...perhaps if MS just documented it a bit better, but still...
Definitely, here is what I'm working on:
I am making a tool for a technical support team to track incidents that impact our customers. The support team needs to have the ability to escalate the incident to the engineering team. The process that we have established is to notify a few members of the team and have them update the incident item by assigning an engineer to the incident. I created a SharePoint list with various fields about the incident, an option to escalate to the engineering team and a people picker for assigning and engineer to the incident after escalation.
I setup a flow to send an email notification to a small team asking them to assign an Engineer. To ensure that someone is assigned, I added a do until loop to send another email after 24 hours if an engineer has not yet been assigned.
After struggling with figuring out how a Do until loop works and some great help from JKarlo I finally setup my list and flow as follows:
List (Simplified for this example)
Setting Escalate to Engineering is my trigger to send an email. Here is how I setup the flow:
First Condition is to check the Escalate value:
Next, the do until loop. The order here gets a little weird if you are not familiar with flow and how a Get data works compared to the Create List Item data.
Configuring the Get – selecting the ID that the workflow holds under the “When a new item is created” data set. The workflow will query the list at this point and get the current information for the same list item that initiated this workflow instance. If it is not obvious, the “When a new item is created” data set is all the data in each of the list fields at the point when the list item was created and is stored in the workflow instance. In this context, it is filtered to only the list item ID. When I set the Do until condition, I have a screenshot referencing a larger set of data at that point in time.
Now for the Do until condition. When you first attempt to choose a dynamic value to use in the condition, you are presented with the “When a new item is created” data set. Here is where I made my first mistake! If you select any field from this list, you are selecting the data when the list item was created! That data doesn’t change no matter how long you wait. You must scroll down and view the next data set.
After scrolling down, you will see the data set from the Get. It has all the same fields because it is the same list, but this data is what is retrieved when the get runs. In my setup, that would be after the 24 hour delay that I configure in the delay action. As you can see in the screenshot below, the Get data set is headed up and contains the same fields but the data stored in those fields was from the time when the Get action ran and so could be different from when the item was created. In my case, I want to check if an engineer has been assigned so I selected the AssignedEngineed Email.
Unfortunately, the condition does not have an expression for “is not null” so I must switch to the advance mode. Here is what it was when I switched to advanced mode after the screenshot above. NOTE: I change the Count limit to 3 for testing purposes. This is the master limit and will stop the flow regardless of wether the condition is met or not!
I want to continue this loop until the AssignedEngineer after the Get action is Not null, so this is how I modified the expression:
Done. I didn’t show screenshots of configuring the email or delay, but those should be easy. This flow will email every 24 hours asking for an Engineer to be assigned, until that happens.
I realized after I wrote this that IF an engineer was assigned at the time the incident was first created, then 1 email would be sent because the do until would only stop after the first Get, which only happens after the first email is sent. Easily dealt with by adding another condition before the Do until loop that checks if the AssignedEngineer email from the “When a new item is created” data set, is blank:
Let me know if this is still as clear as Mud and I can be more verbose. After a frustrating time getting this working, I'm actualy glad that in a single workflow instance i am able to have both the original list data and an updated version!
Answering an very old post. But i have the issue if i use a variable as a string my condition will not be affected in anyway. As soon as i turn my variable into a integer it works
Check out the new Process Advisor community forum board!
Check out new user group experience and if you are a leader please create your group
On-demand access to all the great content presented by the product teams and community members! #MSBizAppsSummit #CommunityRocks