I would like to ask if Camunda Modeler supports the creation of a Multi-Instance Pool.
I want to model my process on a Collaboration Diagram (like below) and in the 2nd Pool I have multiple users with the same role (User B). The only 2 types as I saw for pools configuration are Expanded and Collapsed.
@Niall, I can’t distinguish the difference between “model for reporting” and “model for execution”. Of course, I want to execute the above model if this is what you asked.
My scenario here is this one:
User A creates a list and sends it to 6 users (all with the same role within the process).
Each one of those users works independently and sends back his own list to User A.
User A must receive 6 different lists.
Do you consider feasible to model and execute this process within the above collaboration diagram?
In some case a model is created for documentation rather than execution. Since you intend to execute this model then what you’re trying to acheive can be done the way you’ve modeled it. But i think it would be slightly better to do it as a multi-instance Call Activity.
In my above model, the Subprocess (where concerns User B) is called by the Main Process (where concerns User A) and I ask this because I would prefer to display the details (“List Received”, “Edit the List”, “Send back the List”) of the called process.
I would like to ask what is the difference (for Camunda BPM platform) between a model for “business reasons” (as @kontrag mentioned) and an executable model. In other words, the first case is only for displaying and explaining the flow of a modelled scenario out of the scope of Camunda ?
It’s regards the intention of the model.
BPMN happens to be an executable notation, but it doesn’t mean it has to be.
In some cases the goal of you model may be to convey the details of the process to someone. In which case attention to detail is not required and in fact attention to how the BPMN notation actually functions can be ignored - provided you convey the intention of the process this i know as a strategic model a model that will never be executed but will help understand the high-level process. executable models are sometimes built using strategic models as a starting point but must be more precise because its intended for them to actually run as they are described.
Ok @Niall, you really made clear their difference, thank you.
So, in my case, I have to save both of those 2 models (the one with message flows and the second without message flows as @kontrag suggested) but only one of them must be included and participate in the deployment and execution of my process.
The other one is kept outside for theoretical purposes only if I correctly understood.