RussellJ

Yes 😀 Over to you to try it out in your Dev environment...

(The rather odd looking second clause "not equal to true is true" is because I want to include both false and null values, and the drop down list of conditions doesn't allow me to check for that combination)

dkuroda in case an image helps, here the kind of scenario mentioned by Amy J. (but in an IF rather than a Trigger, but the idea is the same). The first image is the IF block in the Recipe and the second shows the details of the Fields (note both are in Formula mode)...

Hey vivek that's great to hear! Appreciated seeing the detail of your tests & findings. Hopefully it works in your Production solution - let us know. As per an earlier reply, if it were me I'd also want a variable to track the number of times I'd been round the loop and also be able to exit if that exceeded a certain number, just to make sure we're not stuck forever. As soon as you've come out of the WHILE loop I'd then check the value of the variable and maybe flag an error/send a mail/something if we exceeded the number. LinkedIn invitation sent!

vivek sounds good - keen to hear how you get on, and I'm sure your update will be of value, regardless of what you find! If there's an issue with calling the WAIT action again with "stale" Job Ids, it also occurs to me that it might be possible, after invoking the WAIT action each time, to query the Results array in the action, checking for Jobs where Job Completed At is NULL (which I assume would be the timed out ones)? Then you could invoke a new WAIT action with just those Ids? But fingers crossed that's not necessary and you can simply enclose the WAIT in a REPEAT.. .WHILE block 🤞

Hi vivek. I don't have any insight from previous experience or best practice to share, but a couple of things occurred to me so I thought I'd jot them down so you had some response until someone with real knowledge comes along 😀 Firstly, and I know it's not what you'll want to hear, but 24 hours for any (third party) task feels like an awfully long time. Does whatever this is really need to take that long? Is there any scope for optimisation there? Secondly, from a peek at the "wait for an async call to complete" action, I can see the output from this step has a number of "count" values - Job succeeded, failed and timed out (see attached image below). Which immediately makes me think you could check the value of "Job timed out count" after the wait step. If this is zero, you're good to continue, if not, could you just invoke another wait step (using the same job ids?) Or perhaps instead even just place your original wait step inside a REPEAT... WHILE block and only exit if "Job timed out count" = 0? But if doing that I think I'd want to keep a count of how many times I'd been round the WAIT loop and exit with an error if that was more than a defined number (to prevent waiting forever)! However, like I said, I have no real world experience of your scenario. But perhaps if I've speculated unwisely, this post might at least prompt someone more knowledgeable to post a correction! 🤣

Hi sonal Without more information about what you're trying to achieve or the difficulty you're facing it's difficult to give more of a reply. Apologies if this is too basic, but a common way of exiting a loop is to test for a condition and then use that in the WHILE action. See the screenshot for a sample...

Hi sonal when you say "parent loop" do you mean a Repeat... While loop?