After you’ve used Signavio Workflow to model and execute a number of business processes, you can expect to have a number of complex process models. To prevent this becoming a problem, you should learn how to simplify your process models. This article introduces one technique for doing this: using BPMN collapsed sub-process activities as custom activity types.
Consider the example of athat models an interaction between a document author and a manager who approves the document.
Workflows often include this, so you would save time if you didn’t have to model the pattern every time you wanted to approve a document as part of a larger workflow. For example, a process for preparing and distributing a sales report might include the same approval step as a commercial proposal process.
To make the document approval reusable, first model it as a standalone process, called ‘Approve document’. The process requires some information to work with, so add a trigger form with User fields for the document’s author and the reviewer, plus a File field for the document that the reviewer will check. Assign the two user tasks using the corresponding role – Author or Reviewer.
Now, publish the ‘Approve document’ process so you can use it as ain a process that requires a document approval. Configure the sub-process inputs by using the binding (chain link) icon to choose a suitable document and roles for the approval. For each input, which corresponds to one of the three sub-process trigger form fields, select a variable from the parent process that has the correct type.
Similarly, select the Outputs tab and configure the sub-process to update the original document. You may also want to capture additional information from the approval sub-process, such as review comments.
Now ‘Approve sales report’ appears as a single action in the process model, which has two important benefits.
These benefits result from using the document approval as if it were some kind of custom activity, or as if it were built-in to. Sometimes you get other benefits from using a sub-process, so consider another example.
Banks typically have a complex customer onboarding process that includes a number of checks that the customer’s application must satisfy before the bank accepts the applicant as a new customer. In particular,(KYC) legislation specifies a number of checks, to help prevent illegal activity such as money laundering.
This simplified example of a customer onboarding process starts with KYC checks that validate the name and address, check that the name is not known to Interpol or on a politically exposed person (PEP) list.
Specialist staff in a separate fraud department actually perform the KYC checks. The customer onboarding process ensures these checks happen at the right time but does not specify how the fraud department will perform the checks. In fact, the customer onboarding process owner probably doesn’t know exactly which checks are required.
The solution is to extract a ‘Perform KYC checks’ sub-process that the fraud department can model separately. That way, they can decide which checks to include, and simply provide the result of the checks to the top-level process.
When a separate department performs part of a process like this, the process owner can delegate the process modelling to the other department using a sub-process.
This idea of separating responsibility for automating part of a process leads to an important special case. Sometimes, a process requires a programmer to write some code.
Suppose you have a workflow that includes a form field for entering a birth date, and you want to check that the birthdate is in the past, to help prevent errors. In, you can do this kind of thing by using a script task to write code that performs checks on workflow variables that you cannot implement with conditions in an exclusive gateway.
In general, workflows may require special business logic or integration with other systems that requires some code. For example, the following script task configuration shows the (small amount of) code that performs the birthdate validation.
Ideally, a programmer would be able to implement the required functionality without needing to access the parent process model. As before, the solution is a sub-process that only contains a single script task for the code.
From the parent process modeller’s perspective, they can use a ‘Validate birthdate’ sub-process that takes an input birthdate and provides a Yes/No result. Again, this sub-process acts like a custom activity type. This scenario introduces another benefit.
Together, these examples show how sub-processes have a subtle power that you can leverage to help simplify process models, and their design and maintenance.
In summary, maintaining many complex business processes includes a number of challenges.
Identifying common modelling patterns and separate areas of responsibility, and extracting the corresponding process model sections into sub-processes has several benefits.
Sub-process activities are therefore an essential tool in your BPMN process modelling palette. Using sub-process activities to call processes that behave like custom activity types gives you one way to make this straightforward to understand.