Call Activities, Event Subprocesses, and Triggering Subprocesses Across Pools

Hello,

I am creating a BPMN diagram with 3 pools (1 internal pool with departments as lanes), a second pool for an external administrative partner, and a third collapsed pool (client).

In my process, there are 2 subprocesses that are triggered multiple times.
Subprocess 1 is a process that will be triggered multiple times by department 2 when sending mailing lists to external participants.
Subprocess 2 involves uploading a status list to an application, where depending on the type of list, a specific folder needs to be placed, after which a script changes the status in the application. Subprocess 2 could be triggered multiple times by both Department 1 and the external partner.

I want to represent both subprocesses as visually as possible in the diagram, which is being created for a report. My questions are:

  • Should I consider including the external administrative partner in the big internal pool for better representation?
    
  • When is it best to use a Call Activity and when an Event Subprocess?
    
  • How do I model a Call Activity and link it to data objects?
    
  • What is a good approach to enable Subprocess 2 to be triggered in both pools?
    
  • Can a call activity be triggered in a similar fashion as a activity sub process? 
    

I would like some insights into these issues to correctly and clearly construct my BPMN diagram. Thank you in advance for your help!

Link to current diagram

Hi Coldpak, welcome to the forum!

I am a bit unsure about certain aspects of your process model. If the model is meant to be a strategic process model, I have a few suggestions:

  • try to model only the most important aspects and focus on the “happy path”
  • do not use BPMN elements that are difficult to understand like the event-based gateway
  • you can use the “loop marker” to show that an activity is repeated
  • the model does not need to be semantically correct

I added an example for a strategic model, I removed various details, including the reminder or how the subprocesses look like in detail.

If your model is meant to be an operational model showing every detail of the process, here are some other suggestions:

  • separate all participants into separate pools
  • show how the participants get involved (message start event,…)
  • model semantically correct
  • add a task type to each task (service, user,…)
  • use the multi-instance marker (parallel or sequential) to show that a task or subprocess is repeated
  • try to model every single detail of your process

Here are some general comments on your model and your questions:

  • using message or escalation events to trigger an event-based subprocess in the same scope is not how messages or escalations are meant to be used
  • call activities with an extracted BPMN model is a good idea if the model needs to be reused
  • you cannot use the same receive task behind multiple event-based gateways. You can duplicate the task insted
  • try to model the happy path on a single horizontal line from start to finish (the reminder is not the happy path)
  • one start event and 2 end events are missing
  • please add labels to your events and also the exclusive OR gateways
  • an event subprocess is used to model a functionality that does not necessarily need to happen. A call activity is different, it simply stands for an extracted BPMN model. When it comes to messages and signals, a call activity can be triggered in the same way as an event-based subprocess.
  • you can model a call activity by creating a task, selecting the wrench icon and clicking on call activity
  • use data objects sparingly, and if you use them, label them properly. Often data objects are not necessary

If your model is meant to be an operational model, we can work on that together! Currently, I am unsure how the subprocesses are meant to be triggered multiple times. Is there some kind of loop, based on the outcome of a task,…?

Best regards, Till
08-02-24-strategic-model.bpmn (10.7 KB)

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.