• State Not Answered
  • Replies 6 replies
  • Subscribers 7 subscribers
  • Views 3540 views
  • Users 0 members are here
Related Discussions
Home » Discussions » AI and Rules

Today I found a problem regarding evaluation of logical functions and boolean va

Stefan Helzle
A Score Level 3
Today I found a problem regarding evaluation of logical functions and boolean variables with null values. The function "and(null())" evaluates to "true", "or(null())" evaluates to "false" and "not(null())" tells me that null parameters are not allow. Adding some true() or false() values to the and() and or() functions return correct values.

When I bring the if() function into play which always handles null() values to false() the whole behaviour looks quite inconsistent to me. I think that "and(null())" as well as "or(null())" should evaluate to "false". The function "not()" should take null() values as "false" and for consistency "not(null())" should evaluate to "true"....

OriginalPostID-125072

OriginalPostID-125072

  Discussion posts and replies are publicly visible

  • 0
    Appian Employee
    Please check out our Logical Function Documentation that outlines the behavior of each logical function. Specifically, note the sections within each logical function that describes the behavior with respect to null value.

    forum.appian.com/.../Logical_Functions.html
  • 0
    A Score Level 3
    I know that documentation. I know that using an AND or an OR with only one parameter does not make much sense. My main concern is that NOT with null() throws an exception. To have a NOT function that is save I would need something like if(pv!abc, false(), true()). But do we want that?
  • 0
    Appian Employee
    For the logical functions: AND OR, null values that are part of input arrays are filtered out before evaluation. In both cases, since the null value is removed; the AND, OR functions return their default value when faced with an empty array. For AND, that value is true, and for OR, that value is false.

    NOT works a little differently then the preceding 2 functions, as you had noticed. NOT requires a boolean value since it needs to be able to convert to its complement. That is why there is an error generated when null() is used in NOT, whereas AND OR functions return outputs.
  • 0
    A Score Level 3
    As a computer scientist I understand that very well as well as the surrounding implications. What I want to say is: Do we want to bother a process designer with this? Even I would want a NOT that handles a NULL like FALSE for example just because I do not want to think of a 3-state boolean.

    In more than 5 years with Appian I had several cases like this. Maybe we can get rid of one.

    Maybe someone is listening who is in Amsterdam next week so we can discuss this.
  • 0
    Any Appian PV or Data Type can have a null value, so you are correct that it's not a conventional boolean.

    However, I would guess that there are a lot of processes out there that depend on null() being a different value from false. For example, before an approval PV is initialized, it's not false or true. So you might distinguish between cases that are approved, rejected, and pending.
    It's possible this is not a design best practice (I can ask Appian PS what they think) but changing the behavior here -- and making the Boolean type behave differently from all other types -- could have a lot of implications.
  • 0
    A Score Level 3
    Thanks Lizzie, changing behaviour in a product is always a problem. For me there a lot of functions in Appian that react a bit different on these edge cases. NOT throws an exception, IF interprets NULL like FALSE, AND returns TRUE. This looks awkward to me ....

    I love Appian for being such a great platform and I see that you are doing a fantastic job in holding all the pieces together. And then there are these little things ...

    I will add this to my personal in-brain knowledge base :-)
© 2024 Appian. All rights reserved.
We want to hear from you! Submit a review on Gartner or G2.