Students in my BPMN Method and Style training are often befuddled by how to start a process. I see Conditional events, Error events, all kinds of things. No, stop! While the BPMN spec provides many different types of start events, only three of them are relevant to the non-executable flows most modelers are trying to create. In Method and Style, those are the only ones allowed. This post will explain.
Just Three Ways to Start
There are really only three ways to start a process:- On external request. Here "external" means some person or entity that is not a task performer of the process. The Customer, for example, is always external. Even in internal employee-facing processes, the requester can be considered external if he or she performs no activity in the process, merely requests it and receives back some final status. By far the majority of BPMN processes start on external request.
- On a regular schedule, for example on the first day of every month, or every 10 minutes. In non-executable BPMN it doesn't matter whether the process is initiated automatically or manually, as long as the process runs repeatedly on a schedule.
- Manually by a task performer. Occasionally, a person who performs tasks in the process initiates it manually. Some employee-facing processes work this way, although in many cases the initiator could be considered an external requester.
Message Start
A process that starts on external request uses a Message start event. Method and Style says the label of the event should be "Receive [messageName]" and requires an incoming message flow labeled with the messageName. The messageName should be just a noun - the name of the message, like "Order" - not an action like "Receive Order" or a state like "Order received".
The great thing about Message start events is that they tell you right away what the process instance represents. A process model defines a flow that is performed repeatedly in the course of business - not continuously - where each repetition, or instance, of the process has a precise start and end. Understanding the process instance is crucial for creating properly structured models, but students initially have a hard time with that. With a Message start event, it's easy: Each instance is the handling of that start message, such as an Order. The reason this is important is that the instance of every activity in the process must have one-to-one correspondence with the process instance. (That is not Method and Style; that is from the spec, although not clearly stated as such.) So, for example, if the Message start event is "Receive Order," every activity in the process must be performed per Order. An activity that adjusts discount codes every month, while related to this process, cannot be part of the process. It must be part of a different process. We'll see an example of this later.
Timer Start
A process performed on a regular schedule, whether initiated manually or automatically, uses a Timer start event. The label of the event should be the frequency of occurrence, such as "Monthly" or "Every 10 minutes".
Again, the start event identifies the process instance: It is that single occurrence. And again, every activity in the process must pertain to that occurrence, not a previous occurrence or future occurrence or some individual request received during that occurrence. For example, suppose there is a Project Review process that occurs monthly. The start event is Timer with label "Monthly", and each instance is a single monthly occurrence. Suppose time runs out to cover all the issues, and some are deferred to next month. A gateway that loops back to the start to handle those would be incorrect! Handling of next month's issues occurs in next month's instance of Project Review.
None Start
A process initiated manually by a task performer uses a None start event, with no trigger icon.
It's unfortunate that BPMN does not have a Manual event trigger, so manual start must use None start, which is also used for the start event of subprocesses (which are started by the incoming sequence flow, not an event) and also loosely specified processes where the start conditions are undefined. In manually started processes, the instance is not easily determined.
Fortunately, these processes are fairly uncommon. I find in most cases where students use a None start, the process is actually in response to an external request, so Message start would be correct.
Instance Alignment
As I mentioned, the BPMN spec requires that instances of all activities in a process must align with the process instance. Otherwise they must be modeled in a separate process that interacts with the first process either via message flows or a shared datastore. Let's return to the case of an Order process that involves discount codes that are updated monthly. The activity that updates the discount codes cannot be part of the Order process because it is performed monthly, not per Order. It is part of a separate process, Update Discounts, modeled with a Timer start event labeled "Monthly". The activity of validating the requested discount code against the current list is done per Order, so that is part of the Order process. The link between the two processes, which must be modeled as separate pools, is the datastore "Discount Codes". The datastore is updated by the Update Discounts process and queried by the Order process.
