@cbuchberger we follow a similar example for dealing with “services” for governments.
In our case we have a Service that has Service Scenarios:
A Service is a parent grouping used as a generic item: Request a Server
A Scenario is a sub item that has the actual bpmn activation attached to it: Request 1 Server, Request Multiple Servers, Request Server - Priority
The reason for different scenarios is the ability to reuse BPMNs across scenarios as a “Generic” bpmn and the BPMN is injected full of variables.
So this leads to cases were we have many sub-processes that can activated based on the uniqueness of the client and their departments: similar to your IT services and your specific clients that have specific workplans, and workplans that are specific for certain services or groups of IT infra/tech.
A few assumptions i make based on your description:
- The top level workplan order is executed in sequential order.
- workplans may be a sudo-workplan that is actually a combination of other workplans
And you end up with something like this:
and you configure the call activity with sequential, so it’s in order (as per your workplan requirement).
And you config your call activity with a variable:
notice how the multi-instance is setup.
And now when you want to run parallel workplans, this is where the “sudo-workplans” come into play; your workplans can also just be a workplan that is executing other workplans in parallel:
Click on the image to see the full length
Where Plan ABC was just actually calling Plan 1 and 2. Therefore in the My Service, you dont need to actually have your Workplan list, have every workplan, just the packages or workplans, and the overall order. The overall order is that “Master” order i mentioned above.
You could also get into really interesting use cases of Signals and Messages from the child processes to the parent service process for things like client reporting of errors or failed deployments.