Anti-patters are modeling patterns wrongly used to model some business conditions. In general, Anti-patterns seem to work fine, but their use is not directly supported or is not BPMN compliant and could make Processes not work as expected. For these reasons, we do not recommend to use Anti-patters.
Below you find some of the most frequently used Anti-patterns:
Avoid following an Event-based gateway by elements other than Events and Tasks
Ex: Cancellation pattern with Parallel gateways
The Event-based gateway provides a useful modeling pattern, which should be used appropriately. Given that this type of gateway will enable and control different possibilities in the workflow. Make sure that this gateway is always followed by Tasks or Events. Other BPMN elements (such as sub-Processes or other gateways) right after this gateway are not supported.
It is common to see processes automated using a cancellation pattern that involves an Event based Gateway followed by a Parallel gateway.
The whole process is canceled if an event is executed or a time is reached before a set of activities is completed, otherwise, the cancellation logic is disabled.
On the left the most common way to model this cancellation; this kind of pattern it is not BPMN compliant and, therefore, is not supported by Bizagi.
On the right an alternative way; An additional event is used to discard the cancellation logic once the necessary activities are accomplished.
Never use signals or messages in embedded sub-processes
Embedded sub processes (a.k.a. Modules) should not contain signals or messages. These may cause the sub-process to be opened whilst waiting for something to activate them, and not allow the parent process to finish correctly.