Messages and Sequences in a ‘Requesting Feedback’ Process
Blog: Process Modeling 2.0
In a linked-in question on the BPMN group, Lotfi Al-Hussami posed a basic modeling problem in BPMN. Quoting here:
“As an example, we have the following process that we will call “Get feedback”:
– A company X “Send forms” to people by e-mails
– People fill forms, so every person receiving the message “Fills form”
– Company X “Process forms”
At first glance this looks like a pretty simple problem to solve, as shown in the process below. If the process merely prepares the correspondence then our process, ‘get feedback’ will handle the messages as shown below:
So the location of the intermediate event is dependent on what level the process is responsible for the messaging. Strictly reading the name of the first subprocess in our example the first example is probably most correct. Also, we are using the external black-box pool to denote the customer.
The Survey Pattern
In many cases, organizations want to aggregate feedback. Sometimes a process gathers data from an unknown number of participants. The process requirement wording might be:
- Request feedback from at least %20 of the customers.
- A minimum of 20 participants are required for the class to be scheduled.
The process does not know the number of instances of an activity at run-time. We can use a survey pattern when we don’t know how many responses or instances of an activity happen. Here the process must wait until all instances are completed. Then other activities start. Often, while some activities execute or are completed, new ones might be created- your process might ask for more responses. This
A Survey Process
The figure below presents a model of the survey, marketing or feedback scenario. In the example an email form invites a response from customers in the process. The loop awaits a satisfactory response, as determined by a decision. Here is a short description of the process:
- An incoming message starts a survey. The ‘email Recipients’ task send email to a mailing list.
- The survey process loops for incoming email. The results of the survey are tallied by the ‘survey decision’ activity, which calls business rules that decide the adequacy of the survey.
- A gateway decides if the survey results are satisfactory. Usually the gateway is optional. BPM tools specify the looping conditions.
The black box pool shows a notation, verticle bars, for multiple customer participants.
Other examples of the usages for this pattern include:
- Getting bids for work from multiple trading partners,
- Awaiting the delivery of multiple shipments from vendors to a facility before completing a process.
The multi-participant pools should be displayed in this case. You assign this pattern when the process must respond to multiple unknown quantities of events.
The elements of the pattern are:
- A request from multiple sources by email, messaging, html or other sources
- A loop that awaits the arrival of information from these sources
- A decision to approve the survey and business rules for this decision: a call to the rules engine to decide when the survey response is satisfactory.
A process that receives the request and loops between the approver and requestor until the approver is happy with the request.
Cardinality is the Key
Returning to Mr. Al-Hussami example, process-oriented thinking should focus the requirements on a single instance of an interaction. So, a single survey form should be met by a single process response. We can compose a working, single-person survey into a more powerful pattern, such as the pattern that we have described here. When you are working with process requirements in BPMN, verify that you are thinking in terms of the singular entity, and then build your requirements from there.