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.
Never use Message events to send electronic mails
Messages events should not be used to send electronic mails during the process flow. These elements must be used to let a process to communicate with another process.
Electronic mails must be send using Activity actions.
Don't use signals nor messages to activate paths inside the process
Don't use signals nor messages events to activate paths inside the process
Signals are listened by all active processes and it is caught by all the process at the same time. If a signal is used to activate a path in the process this path activates all the active processes, not just inside the process that launched the signal.
In this kind of situation a Conditional event should be used.
A common example, for this kind of situations, is when you want to disable the cancel process event.
On the left and middle the most common ways to model this cancellation; these kind of patterns are not BPMN compliant and, therefore, are not supported by Bizagi.
On the right an alternative way; A conditional event has replaced the signal/message event with a script task which activates the event.
