Anyone else noticed this quirk with the AND gateway and chaining?

RE: Anyone else noticed this quirk with the AND gateway and chaining?

Naresh — Sat, 07 May 2022 17:18:18 GMT

This is very interesting, I didn't about this behavior about AND condition. good to know.

RE: Anyone else noticed this quirk with the AND gateway and chaining?

Mike Schmitt — Fri, 06 May 2022 16:09:20 GMT

AFAIK if you try to chain multiple out flows from an AND, all bets are off. That's sorta congruent with what we saw in my initial results here (though from an opposing perspective, as it were). The only frustrating part is that there's no mention of this in any of the official documentation, at least per what I could find with an initial check.

RE: Anyone else noticed this quirk with the AND gateway and chaining?

davel001150 — Fri, 06 May 2022 15:54:13 GMT

Also, say you have AND with 5 different forms chained to it. Which will the user actually see?

RE: Anyone else noticed this quirk with the AND gateway and chaining?

davel001150 — Fri, 06 May 2022 15:53:17 GMT

I think you'll find some very interesting things. Accordingly, if you have an OR gateway, and all the outgoing flows are valid, then the documentation SAYS that one of the flows will be first randomly.

However, when I tried it, I consistently got one of the flows to finish first when attempting to create a race condition. (Fun to have a PM be your random number generator; sad it didn't work.)

RE: Anyone else noticed this quirk with the AND gateway and chaining?

Mike Schmitt — Fri, 06 May 2022 13:37:47 GMT

Yeah, you're all probably right - it just took me by surprise.

RE: Anyone else noticed this quirk with the AND gateway and chaining?

Mike Schmitt — Fri, 06 May 2022 13:37:24 GMT

[quote userid="85715" url="~/discussions/f/process/24514/anyone-else-noticed-this-quirk-with-the-and-gateway-and-chaining/94713#94713"]each AND opening gateway shall have "closing" gateway, which would mean you should have a second AND gateway before your "end event", [/quote]

Good point, I never realized this.

RE: Anyone else noticed this quirk with the AND gateway and chaining?

Stefan Helzle — Fri, 06 May 2022 05:54:51 GMT

Seems like a variant of the classical race-condition to me. While being tricky, I think that this is expected behaviour. This design basically says: "Kill the process instance ASAP ignoring other flows".

RE: Anyone else noticed this quirk with the AND gateway and chaining?

Richard Michaelis — Fri, 06 May 2022 05:53:10 GMT

Not realized, but not sure if its real bug.
Appians defines chaining as "If the completion of a task in a process requires the same user to complete a subsequent task, you can activity-chain the two tasks together in your process model."
https://docs.appian.com/suite/help/22.1/Process_Model_Recipes.html
-> This means to me, that you define a "please do these tasks in priority then the rest".

second - BPMN Best practice -> each AND opening gateway shall have "closing" gateway, which would mean you should have a second AND gateway before your "end event", which would solve your issue as it waits there until all flows arrived before going to the end event.
-https://www.visual-paradigm.com/guide/bpmn/bpmn-gateway-types/

RE: Anyone else noticed this quirk with the AND gateway and chaining?

Mike Schmitt — Fri, 06 May 2022 01:47:52 GMT

It may have always been this way without me noticing - so in that respect expected. But it took me by surprise (unsurprisingly, it was set up this way in the system i inherited, so of course it consumed some troubleshooting effort on my part, and since the model in question was slightly more complicated, it caught me off-guard more easily).

RE: Anyone else noticed this quirk with the AND gateway and chaining?

ChristineLHutchison — Thu, 05 May 2022 22:21:15 GMT

I have seen this before, especially since you chained the one. It was prioritized and terminated before the other path started. This is why you can't terminate or you have to have them come back together before terminating. I believe it has always been this way, and dare I say, expected.