BPMN 2.0: Two successive intermediate events

Hello Markus,

I just tried your case and had no problem making this connection. Also placing the Message event on the connection between the timer and the gateway worked as expected (in Entire Method filter in a BPMN process diagram).

What could be: Your method administrator might have removed some combinations of symbols from the method filter.

I understand your example as "we will not accept the incoming message, if it comes earlier than the wait time".

Hi: 

Thanks for the quick response. So, it is not due to a lack of BPMN modelling rules understanding:-). 

It is an example for a lecture I have to prepare. I am not an expert in BPMN modelling, however I have the luck to teach this subject to Bachelor students in the upcoming semester, and I thought ARIS would be a suitable tool for the students to learn BPMN. 

In short, the detailed example is as follows: 

The HR department forwards an application to the corresponding functional department and waits (clock) until the experts from the functional department send a decision for the application which is either invite for interview or not. So, I wanted to use the two events clock (for waiting) and receive message successively.  In the following picutre you see that it is not possible to select a succussive intermediate event if I use the selection possiblities of a already placed event:

Well, I am the owner of the ARIS Cloud basic and I have access to the ARIS administration panel (I use the academic license). Where can I adjust the the modelling rules? Should it not the case that the BPMN modelling rules are set by default?

Best,

Markus

Hello,

maybe take a closer look at the "three dots" symbol next to "Find symbols". It allows you to customize this popup menu with more or less symbols. It's your choice to have the symbols there that you need often.

Also, your description of the task does not fit your solution attempt. If the functional department responded earlier than the wait time, you would still wait the entire time and possibly even lose the message that arrives early, because your Receive message event is not listening, yet.

This would be my solution:

A receive task waits until a message is received. Here a timer event as a border event defines for how long the wait should last at maximum. It is an interrupting timer event, so the task "Receive feedback" will be aborted and the flow will continue with whatever they do in that case, if no response is received. If a feedback is received indeed, the process will continue immediately with "process feedback" and the timer is obsolete.

Hi: 

Thanks a lot for the modelling advice! Helps a lot and makes also a lot of sense. 

However, the event follows event problem is still there. Is there a possibility to have a support call? For the lecture it would be really helpflul to have all possible modelling rules. Below is a snapshot of the three dots in the find symbol menue. 

Thanks,

Markus

Hi,

have you tried typing something in "Find symbols"? Like so:

Then select the symbol you need and afterwards it will be available in the quick modelling bar:

If you want the full selection of symbols, you can show and hide the symbol palette with the toggles in the top right corner:

Then you select the symbol you need from the symbol palette, place it, and draw the connections with the connections tool:

Hi Markus,

If I understand your example correctly, there should not be a need for two consecutive Intermediate Events. By definition, the Intermediate Event is already a wait-step with a condition attached - i.e. the process cannot proceed until the condition has been fulfilled. 

Including a Time-Based Intermediate Event is specifying that the process cannot proceed to the next step until the specified time period (usually either in X number of hours/days, or based on a specific date/time - such as Mondays 9am). Where a message-based intermediate event exists, this is showing that the process flow cannot continue until that message event has taken place.

In your example, I understand the HR department is forwarding an application, then cannot proceed until the response is received. Including a message-based intermediate event will represent this effectively - there is no need for a time-based wait step here in addition. 

Hope this helps,

Gavin

Hi Markus,

we just confirmed that this limitation results from the usage of a restricted method filter, which does not contain this connection between events. In the administration set "Entire method" as the Default filter for your database. This way you will get access to the full set of modelling possibilities of BPMN Collaboration diagrams. After changing the default filter of the database you have to log out and in again to activate the new filter setting.

The use case for restricting the method via a filter is that method administrators in the Center of Excellence want to enforce not using certain modelling patterns. I will not discuss what might have been the motivation for this restriction in this case, because I just don't know.

Regards, M. Zschuckelt