Skip to main content
January 14, 2025
Solved

Contradiction in XOR Evaluation Order Documentation

  • January 14, 2025
  • 14 replies
  • 0 views

This is more of a PSA post rather than a question, but I thought I'd put it up here to a) help anyone else out who is confused by this and b) hopefully get Appian's attention to fix this (I will also make a support case for this issue).

This is regarding how the XOR node in the process modeler evaluates multiple conditions. Looking at how the Decision tab is laid out (with IF...ELSE IF...ELSE IF labels and the ability to change the order of the conditions) my first thought would be that the conditions evaluate in order from top to bottom.

However, in the documentation for this node it states: 

  • "Conditions are evaluated in bulk, without regard to the order in which you list them."
  •  "Do not stack gateway conditions such that the first condition must execute before the second condition is evaluated. To avoid this, write the primary condition into the secondary one to ensure that the desired logic takes precedence." 

But then in other places the same page states: 

  • "Each outgoing path is assigned a condition. The conditions are evaluated according to their top-to-bottom ranking. As soon as a True condition is discovered, the workflow takes the associated path."  
  • "If you have more than one condition, reorder them so that they are evaluated in proper sequence. The first condition listed is the first to be evaluated." 

The actual behavior of the XOR node indicates that the order of the conditions does not matter, all are evaluated simultaneously. I hope that Appian changes the behavior of the node to execute conditions in order as this would be much more useful.

If I have misunderstood anything in the documentation, please feel free to correct me, because as of now I don't really see any value to an XOR node when compared to an OR node.

Best answer by jackf0001

I ran into an issue with this today, but I believe I have figured out why. My problem was that condition 3 was throwing an error, but (in my mind) condition 3 should never have been evaluated because condition 2 was true (which prevents that error). Basically, I was expecting it to operate like an a!match statement. However, we're now thinking the node evaluates all conditions at the same time, and then takes the path of the first (topmost) true condition. This would make much more sense and explain why both "conditions aren't evaluated in order" and "condition order does matter" are present in the documentation. I think the documentation could make this a lot clearer though.

14 replies

stefanhelzle0001
January 14, 2025

I think this is more a mishap in the documentation, than a problem in the implementation. I never had  an issue, but strictly follow the if..else top-to-bottom approach and never had an issue.

 [mention:6b9f80ff18f9420082d13ef2d5121d56:e9ed411860ed4f2ba0265705b8793d05] , what are your thoughts?

jackf0001AuthorAnswer
January 14, 2025

I ran into an issue with this today, but I believe I have figured out why. My problem was that condition 3 was throwing an error, but (in my mind) condition 3 should never have been evaluated because condition 2 was true (which prevents that error). Basically, I was expecting it to operate like an a!match statement. However, we're now thinking the node evaluates all conditions at the same time, and then takes the path of the first (topmost) true condition. This would make much more sense and explain why both "conditions aren't evaluated in order" and "condition order does matter" are present in the documentation. I think the documentation could make this a lot clearer though.

james.lepone
January 14, 2025

The important thing to remember is that all the conditions will be evaluated (as opposed to one at a time until reaching a true condition). What that means is if there are two conditions, one which checks if a list is null, and the next that tries to remove a value of the list, an error will be thrown, since the second condition does not have a null check, even though the first path should be taken. Screenshots attached.

/resized-image/__size/640x480/__key/communityserver-discussions-components-files/14/Screenshot-2025_2D00_01_2D00_14-at-11.15.55_2F20_AM.png

/resized-image/__size/640x480/__key/communityserver-discussions-components-files/14/Screenshot-2025_2D00_01_2D00_14-at-11.16.03_2F20_AM.png

jackf0001Author
January 14, 2025

Yes, this was exactly my issue (getting an error for a condition that I didn't expect to run). I was then confused because, if order didn't matter in an XOR I didn't really see much difference between it and an OR. But I think I have a better understanding of how it works now (see my reply to Stefan).

mikes0011
Brainy
January 14, 2025

Yeah it's unfortunate that it doesn't work like "and()", where conditions that might throw an error can be safely "hidden" underneath prior checks against that condition.  I've just accepted this as one of those foibles you need to get used to - i assume it's in their "process modeler quality of life common sense enhacements" back-lot dumpster.

james.lepone
January 14, 2025

It's actually done this way purposefully, so that if you have some expressions that take a while, we evaluate them in parallel.

mikes0011
Brainy
January 14, 2025

that kinda makes sense I suppose - it's just unfortunate that we are thus forced to do some (sometimes unexpected and sometimes painful) bending-over-backwards to redundantly error-check in multiple subsequent evaluation conditions to prevent crashes.  it seems like a little bit of try() trickery in the back-end could magic this away, in such a way that we only see errors generated when the row in question is actually reached(?!?)