I've got an odd Action Failed error in a loop. I can't look at what the values of the condition are. Nor can I scroll through the results of each iteration like I usually can with a successful flow.
First image is what I"m trying to do, the second is the error I get when I run values through. Note, with this case, I have verified that the User Profile Department contains the string of one row Department in the Excel sheet.
@masisley That may be so, that the cases are running successfully afterwards. I've already implemented my work around successfully and have moved onto another project. If the issue arises in a future flow, I'll have to test that out.
Thanks for your work investigating this, and I'd appreciate if the visual bug is escalated.
@michowl, apologies for the delay in responding.
In my case, the flow I authored had a conditional defined that had a runAfter that looks like this:
"runAfter": { "Condition": [ "Succeeded" ] }
We don't currently expose a way for users to edit these run-after conditions so that you can run these after failure, but it's on our roadmap for the future.
Here's a look at what I did in my flow:
When I ran, though the designer displayed that my actions after the conditional failed to run, in actuality, I was receiving the push notification for the successful cases, and nothing in the failure cases. I think there's a designer bug in how it displays these (I should be able to scroll through each iteration with previous/next for both the push notification and Condition 2). I'll file a bug on this.
Your flow looks a little different than mine. Mine has all of the conditionals defined inside of an "Apply to each", so I'm not sure exactly what the case is for you. It may be that you're running on the succesful cases just like me and the designer is lying to you about what it did.
Best,
Mark
At the end of the day yesterday, I figured that my only issue was the Dynamic Owner Type missing the 's'.
So I tried today to put the loop back together. Tested it with the department in the first row of the array, and that worked fine. Then I tested with the department in the 3rd row, and it again fails. So I think what you mentioned yesterday is true:
"if any of the actions failed in the previous loop we won't run the next conditional. I think this is likely by design."
I'm having a hard time understanding how this could possibly be by design. Could you escalate this as a bug?
Figured it out. I was sending the wrong type for Owner Type. Should have been systemusers, not systemuser.
However, I must say that the error outputs are very misleading for that condition.
What I ended up doing was Filtering the array and just getting the value needed from the first item.
Changed by conditional checks to throw Flow termination actions rather than putting my subsequent actions within the condition.
Nevermind, that is not the case. Ran it again with a Lead that would hit the first entry in the table.
Condition errored out?
If User Id is not empty
But the dependent action blames the condition
Assign Lead to User
I added a compose to look at the output of the condition before the condition action and it returns true.
Interesting, I just reproed the same.
It seems like if any of the actions failed in the previous loop we won't run the next conditional. I think this is likely by design. I'm unfortunately not sure what to suggest here.
In your case did one of the first conditionals fail, or did they all succeed? And your second conditional is inside the same apply to each scope, correct?
@masisley I think what may be happening is that the last condition limits the run of the dynamics action to 1 (because the rest are skipped. So it's trying to see the one run that ran (4) but it's only showing 1 run, so I tried to display the results for Run 1, not Run 4... if that makes sense. Could that be the issue?
So, now that I've gotten thru the first condition (ODATA filter was missing ''s around the email value) I'm faced with another tricky situation. Within that I have a compose that get the id of the first user in the output array from the previous Dynamics Get Records. That's working fine. For run's 1-3 and 5 compose has empty outputs, but Run 4, compose works fine. The condition that follows is an advanced condition: "@not(empty(outputs('Compose')))" to verify that compose has an output before updating a record. But it looks like, from the error messages I see, that the condition is never even reached.
Ah, excellent - Hopefully the error was enlightening 🙂 Let me know if you have any further questions.
Best,
Mark
Foot in my mouth. I guess I didn't click far enough down. I am able to view details of the Dyn calls and found the error. *facepalm*
WarrenBelz
146,645
Most Valuable Professional
RandyHayes
76,287
Super User 2024 Season 1
Pstork1
65,997
Most Valuable Professional