Binary Condition worked for months - then stopped?

[Daryl_K]

I had a Flow that has worked for many months, then out of the blue around the end of March / beginning of April a binary Condition no longer evalauates correctly. The Flow does NOT fail - it succeeds every time, but the binary condition it looks for always evaluates as FALSE - even though I can clearly see there are 10 entries in the list that satisfy the criteria!

This Flow has a special View that no one uses for anything else, and I verified it's still looking at that View (it is). At the beginning it intitializes a Boolean variable called "No" and sets it equal to false. Then at a later point it does an "Apply to each" and cycles through the list comparing a Boolean column value to the variable. If they are equal (the column value is false) it continues down a branch.

That Control succeeds every time, but it returns 100% false outputs, meaning it goes down the "If no" branch after every execution, even though (as I mentioned above) 10 entries satisfy the requirements.

This one has my head spinning, primarily because it worked correctly 100% of the time for 9 months. Now it works incorrectly 100% of the time, and I can't figure out what may have changed!

[Daryl_K]

I should add that despite the Flow using a View that also filters on the relevant binary condition, which leaves exactly 10 list entries, it takes 7 minutes to run through.

This could be a red herring though because I thought I remember that specifying a View only narrows the columns that the Flow looks at, and that Flows do NOT obey the "Show items only when..." conditions in the view. If this is true then that isn't any kind of evidence since the entire list is hundreds of entries long, and 7 minutes to examine them all is not unreasonable.

As a test I added an action under the previously-blank "If no" branch and it executed the same number of times that their is total items in the list. So like I said, it runs sucessfully, but it's like the binary condition always evaluates as false, even though some items should evaluate as true. I checked the column formatting and it's still a binary. The variable is being initialized and set as binary. What's wrong?

[v-zhos-msft]

Hi @Daryl_K ,

Could you please share a screenshot of your flow's configuration?

As you said, the flow worked well in the past months.

Has the data source been modified?

I suggest you rebuild the flow for a try.

Best Regards,

Community Support Team _ Zhongys

If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.

[Daryl_K]

I rebuilt the Flow - no change.

My entire Flow is huge and would not fit well into a screenshot (unless I made it near-microscopic). I don't think this is necessary though because here are the two key steps (shown below).

The first is where I define a variable as a Boolean, set to false. The second is where I do the compare. You cannot see the entire name but it is a Sharepoint column defined as a Yes/No, essentially a boolean also.

So I do a Get Items and compare the boolean column to a boolean variable, and this column, never, ever evaluates as True, even though there are items that would satisfy the condition as True.

I hoped maybe corruption in the Flow, so I rebuilt an entirely new one from scratch and it did the same thing, so clearly there has been an update where Microsoft broke the boolean compare operation. Since this worked for 5 months with this exact same configuration I can conceive of no other explanation.

[Daryl_K]

Correction to my previous statements: it seems the error goes further than just binary.

This particular form has a "Closed" state that indicates the work is done. When an operator "closes" an entry it sets the MIROCN_Closed flag (the one I have been trying to evaluate) to "Yes" and takes their log-in info and copies it into a blank text column as a form of digital signature.

I've been trying to check if the MIROCN_Closed flag is equal to FALSE, indicating the entry is still open, but as this has been wholly unsucessful I tried instead checking field the Closing_Signature is blank. As noted, this field is not visible on the form and is auto-populated when the entry is closed, so checking for it to be blank should yield the same results.

And it does...but not in a good way! Just like the binary evaluation this returns a FALSE 100% of the time, despite the fact 11 entries are blank on that field.

This is driving me crazy!

[Daryl_K · Accepted solution]

Well, the good news is the compare operation is still broken and I don't now why, but I've figured out how to completely work around it by ditching that instruction altogether and using an ODATA filter on my Get items action in the Flow. The filter is simply OCNMIR_Closed eq false which works perfectly since the entire Flow is supposed to ignore entries where that condition is True anyway! As a bonus my Flow runs much faster, though it's a scheduled recurrence that runs at 4:00 AM (every 24 hours) so it didn't really matter. Still...

Anyway, this fixes my current issue I've been struggling with, but the root causal is still there. Does anyone know the formal route for reporting this to MS? I can easily reproduce it and thing they should be aware...