In my last article I described how to create new BPMN objects with the desired symbol. Due to the BPMN knowledge of the ARIS designer, it is impossible to place a symbol at a location, which is not conforming to the BPMN specification. The designer offers exactly those symbols, which are allowed at that location.
Configuration of the visual appearance
In ARIS BPMN designer, the visual appearance of a symbol depends on many factors. All these factors could be adapted with menu entries for BPMN.
As you can see, it is not possible to violate the BPMN specification using the menu. For example, it does not allow switching of a boundary intermediate event to an end event or even to a link event (both are not allowed as boundary objects in BPMN).
The context menu allows choosing between different configurations for activities, for example changing the loop type.
I prefer to use the menu entries of the context menu as shown in the screenshots above. But these actions are also available in the main menu under "Edit -> BPMN".
Changing BPMN symbols and occurrence copies
If you are creating a new object (e.g. via symbol bar), the ARIS designer always creates an object definition and an object occurrence. Both have different properties. The object definition exists only once in the database, but one object definition can have multiple object occurrences. The object definition defines the attributes, like name or description attribute. The object occurrence defines the visual appearance, like size, color and symbol. The behavior of the symbol is different for BPMN models as for other model types.
BPMN 2.0 models have supporting attributes for events and activities, which guarantees that each object occurrence has the same type of symbol.
The type for events is defined as "trigger" in the BPMN specification (none, message, timer, error, escalation cancel, compensation, conditional, link, signal, terminate, multiple).
The type for activities, on an abstract level, is defined as the activity type (task, sub-process, call-activity) and on a more concrete level, it is the concrete task type (abstract, business rules, manual, receive, script, send, service, user), the concrete sub-process type (standard sub-process, ad-hoc sub-process, event sub-process, transactional sub-process) and the concrete call-activity type (referencing a global task, referencing a global process).
Only the type has to be the same, not other configurations. So it is possible to have two occurrence copies of a, for example, message event. The first one is a message start event, the other one is a message intermediate event throwing. Changing the type of one object occurrence to signal event, the type of the other object occurrences will also change. The result would be a signal start event non-interrupting and a signal intermediate event throwing (see the result in the image below).
Note: Changing the symbol type of one object occurrence changes also the symbol type of all other object occurrences of the same object definition. Only the type changes, not other configurations.