Could someone explain why the following code work without compiler errors?
if( isnull(ri!user), "", isusernametaken(ri!user), user(ri!user, "firstName") & " " & user(ri!user, "lastName"), joinarray(split(ri!user, "."), " ") )
I expect some kind of evaluation error, but it works just as the three lines starting on "isusernametaken" were an embedded if.
I saw that in one of the Appian courses and I'm wondering if it is some undocumented feature of the if function.
Thank you
Discussion posts and replies are publicly visible
if() has 3 parameter
condition and true, false statementhttps://docs.appian.com/suite/help/22.1/fnc_logical_if.html
if you like to use morecheck a!match()https://docs.appian.com/suite/help/22.1/fnc_logical_match.html-> this is just a kind of mistake in the appian course. at least unproper use.
Thank you Richard, but why it does not trigger an error or warning in rule designer?
Lets say, as its not completely wrong in the sense that the rule is not technically breaking there is no error message.-> as far as i remember you reported that issue already?
I believe this is the other post: https://community.appian.com/discussions/f/new-to-appian/24293/why-if-takes-more-arguments-than-3
Like others have said, the validation for if() is that it must accept an odd number of parameters (so technically it does accept more than 3). However, this behavior is undocumented and I don't recommend using it.
if() has hidden else if functionality in it. What's documented is:
if(
condition
return if true,
return if false
)
What you can do with it:
condition1,
return if condition1 true
condition2 if condition1 false {else if}
return if condition2 true
return if condition2 false
Or you can do it with 7, 9, 11, 13. Every odd input is another conditional until the very last one, what returns if they're ALL false.
It's way less keypresses, but gets dramatically unreadable.
As others have posted, a!match is basically the same thing in readable format.
Thank you Dave, understood!
Another interesting thing about using if(a, b, c, d, e, [..., ...]) format is that it'll break Appian in places that absolutely require "Design Mode" functionality - for instance, if you try to use it (pretty much anywhere) in the Record Grid Designer. If you use it in a regular interface, it'll cause Appian to refuse to switch back to Design Mode from Expression Mode (though some might see this as more of a "pro" than "con", lol).
I am enjoying a!match. Even now I have a special app package wherein i'm tracking down all the sloppy uses of "choose()" in my system and swapping them out.
I discovered the same last year, I sent email to Appian to ask if its right way to use it. They suggested not to use this functionality and use multiple if statements. Now we have a!match() function for the same functionality.