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!
Join us for the first ever Power Platform Online Conference!
Look out for new contribution recognition badges coming SOON!
We've updated and improved the layout and uploading format of the Power Automate Cookbook!
Fill out a quick form to claim your user group badge now!
Find out where you can attend!
Watch & learn from the Power Automate Community Video Gallery!