Two gates side side

As others have pointed out, there are no "rules" in a process model that preclude having subsequent gateway nodes (of whatever type).  However depending on the process, doing this without careful consideration can create various concerns or potential issues, from design, to visibility, to ease of troubleshooting as well as flow.

A few considerations:

1) in a process instance, you can't open the instance properties of a completed gateway node to see at what time(s) it was executed. I'm not actually sure WHY, but in terms of process troubleshooting this *IS* a visibility limiting factor.  I usually try to have gateways separated at least by a script task if not some other node type for this reason.

2) Likewise in a running instance, it's not possible to "start" a gateway node like it would be possible to "start" a script task or user in put task (or most other node types).  Therefore if you want to start or re-start process execution at a particular gateway, you'd need to have a non-gateway-type node right before it which leads directly to it.  This is often important for troubleshooting as well as O&M.

3) Some gateway nodes (xor in particular) are finnicky about how they can be called if re-executed in one process flow.  Specifically, it can't have 2 nodes both leading to it, because if re-executed from any path other than the path that originally executed it, it will stall and halt the process (intentionally as far as i know, though not SUPER well documented).  Therefore the design guidance here is to always have a single flow into an XOR, especially when there's any sort of looping in the process.

As others have pointed out, there are no "rules" in a process model that preclude having subsequent gateway nodes (of whatever type).  However depending on the process, doing this without careful consideration can create various concerns or potential issues, from design, to visibility, to ease of troubleshooting as well as flow.

A few considerations:

1) in a process instance, you can't open the instance properties of a completed gateway node to see at what time(s) it was executed. I'm not actually sure WHY, but in terms of process troubleshooting this *IS* a visibility limiting factor.  I usually try to have gateways separated at least by a script task if not some other node type for this reason.

2) Likewise in a running instance, it's not possible to "start" a gateway node like it would be possible to "start" a script task or user in put task (or most other node types).  Therefore if you want to start or re-start process execution at a particular gateway, you'd need to have a non-gateway-type node right before it which leads directly to it.  This is often important for troubleshooting as well as O&M.

3) Some gateway nodes (xor in particular) are finnicky about how they can be called if re-executed in one process flow.  Specifically, it can't have 2 nodes both leading to it, because if re-executed from any path other than the path that originally executed it, it will stall and halt the process (intentionally as far as i know, though not SUPER well documented).  Therefore the design guidance here is to always have a single flow into an XOR, especially when there's any sort of looping in the process.