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.
Re-using an approval workflow
Consider the example of a document approval process that models an interaction between a document author and a manager who approves the document.
Workflows often include this document approval pattern, 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 a sub-process in 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.
- Replacing the approval’s two user tasks and a gateway with a single sub-process action has simplified the top-level sales report process, making it easier to read.
- When you make changes to the approval process, every process that includes it as a sub-process will get the new version, ensuring consistency for all document approvals.
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 BPMN. Sometimes you get other benefits from using a sub-process, so consider another example.
Delegating part of a process to another department
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, Know Your Customer (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.
- Extracting the KYC process distributes process ownership to the relevant experts, who can then more efficiently maintain the process without having to coordinate as much with the parent process’ owner.
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.
Hiding code in a script task
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 Signavio Workflow, 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.
- A process analyst or programmer can create and publish a reusable sub-process without any knowledge of the parent processes that will use it.
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.
Using sub-processes as custom activity types
In summary, maintaining many complex business processes includes a number of challenges.
- Model size - individual process models get unmanageably large, leading to errors that require significant time to discover and fix.
- Duplication - many processes include the same common process patterns, leading to inconsistency between processes and additional time to make duplicate changes.
- Coordination - complex models require expertise from multiple people or departments, leading to problems with shared ownership.
- Access - the need to give everyone involved in one part of a business process permission to edit the whole process model, leading to the risk of accidental breakage.
Identifying common modelling patterns and separate areas of responsibility, and extracting the corresponding process model sections into sub-processes has several benefits.
- Simplification - sub-processes hide model implementation details, so that the top-level process model better expresses the business process.
- Consistency - a sub-process provides a single shared implementation of a repeating pattern that delivers better overall quality.
- Delegation - the person with the right expertise can maintain a sub-process model, even if it is only used by one parent process.
- Abstraction - sub-processes can model self-contained tasks that do not require knowledge of the parent process and are thus easier to maintain.
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.