How do you get Appian to process an OR Gateway adhering to the BPMN 2.0 standard

...stance token passes through – until all other incoming flows arrive. Work around this issue by placing an empty Script Task node between the incoming flows and the Gateway node."

For some reason it only pauses "after the first instance token passes through". I don't want the first instance token to pass through, and the work around doesn't apply as I don't want each instance to pass through. I want it to pause until whichever paths occurred complete. How can the standard BPMN 2.0 OR Gateway behavior be achieved in Appian?

Any help is appreciated. Thanks.

Have you considered using the AND gateway and/or COMPLEX gateway to accomplish this use case?
From the documentation for the AND gateway (a lesser-known use of this gateway AFAIK): "If more than one incoming path is used, all incoming paths must reach the node before the process can continue. It is also used to join all incoming paths."

COMPLEX gateways can be further set to meet specific conditions before proceeding, which may be useful in some cases.

Thanks for replying but I don't think if of those options will work. An AND Gateway waits for all incoming paths to continue, as you noted, but in this case not all the paths will be taken in the OR Gateway split so it will be stuck waiting for paths that will never arrive. And the Appian Doc on Complex Gateway states "When multiple flows enter a complex gateway, it allows only the first flow through, despite allowing you to configure it to wait for a configurable number of instance tokens to arrive before activating. Then, the gateway waits until all other incoming flows arrive before activating the outgoing flow again." I have no idea why it would let the first one through "despite allowing you to configure it to wait". This is also not standard BPMN 2.0 implementation, and I can't configure it anyway to wait for N# of paths or specific paths as I don't know for each process instance which paths occurred. That is the exact purpose of an OR Gateway in BPMN 2.0. When the # of paths is determined at run-time, the OR Gateway is specifically designed to wait until whichever paths occurred to complete before continuing. I'm not sure why Appian chose to not adhere to the BPMN 2.0 standard in this one area, but I am hoping someone knows how to achieve a standard OR Gateway split and merge in Appian.

I think (but not 100% sure) that you're misinterpreting what they mean when they say "it allows only the first flow through". I don't believe the implication is that the first flow proceeds immediately - just that only the first flow will (eventually) move on, as opposed to multiple flows moving on.

I tested it and the first flow proceeds immediately.

Can you combine an AND and an OR gateway to achieve your desired behavior?

1) Merge multiple incoming flows with an AND gateway.
2) Use a single outgoing flow from your AND gateway as a single incoming flow to your OR gateway.
3) Configure your OR gateway with whatever conditional logic you require.

Merging multiple incoming flows with an AND Gateway would be stuck at the gateway waiting for any flows that did not occur for that process instance. I tested that as well. In theory I can put a series of XOR Gateways in front of the AND Gateway merge mimicking the conditions of the OR Gateway split. That seems like an ugly solution but perhaps would work. Does anyone know if that is what Appian recommends to achieve standard OR Gateway behavior?

For these situations, I would use a boolean variable in the process instance to decide whether the OR should be executed, or not enough situations have been satisfied. Merge all paths at a script task before the OR where you run some logic to set this boolean variable to true or false. Continue from there to a single path to an OR node. The first expression checks the boolean variable, if false (should not yet continue), run to a non-terminating End Event. If true, check next logic to decide where to route the process and continue.

I think that you should be able to achieve this requirement by adding a pv that tracks the number of optional flows that are active (coming out of the OR). Then, you can wait for that many flows to arrive at the complex gateway before proceeding.