The simple answer to which loop method to use is to express yourself. The specification leaves room for subtle differences, that when combined with some experience in process modeling and some modeling style, BPMN can be very expressive. In some cases there is definitely an incorrect choice for the process at hand, but somehow there never seems to be an absolutely correct one. So here is my style guide on how to pick the best expression for activities that loop.

Style 1: Upstream Loop-back Flow

Example:

Upstream Looping Process Flow

Style expression: Use when you want to do something over again (redo), but not when you want to repeat activities and preserve the previous results. If you want to preserve the previous results I would recommend using the looping subprocess instead.

Upstream looping flow with timer

Upstream flow is also very useful in high-level diagrams where you don’t wish to show all of the intricate details of process flow. I’ve found that if you are using a high-level view, it’s best to stick with subprocess shapes rather than using tasks. A task implies an atomic single activity where something is done. The subprocess expresses that there are several steps to complete a task, which can include the points of communication (message events, signals, or anything else required to complete the activity). I’m not saying that the subprocess is required here. But it might be a better option because it’s more likely to accurately depict the true nature of the process.

Upstream looping flow across participant lanes

Advantages:

• Simple to model and most people with no BPMN training can easily understand it.
• Great for showing high-level sequence flows across multiple participants (roles, systems, etc).
• Easily shows the loopback condition as part of the gateway, without using annotations.
• Allows you you to do a loop across multiple swimlanes, but be cautioned that this is not always a good idea (see my other post about swimlanes).

Disadvantages:

• Doesn’t always capture the detail of a process flow (see my other post about swimlanes) and limits ability to show explicit message interaction between participants.
• Not very easy to introduce exception conditions into the flow without adding a lot of extra shapes.
• Implicit way of showing multiple iterations of an activity might lead to inaccurate interpretation.

Style 2: Looping subprocess

Looping Subprocess

Style Expression: Use when you need to repeat one or more activities while preserving the data/results of the activities for future reference. Also very useful when you need to deal with multiple exceptional conditions that might interrupt the loop iterations.

In the following example I am using the simple “check mail” process. Every hour I check the mail, and if there is something in the mailbox I reply to the mail. When I’m done replying to the new mail the cycle repeats. Immediately after replying to mail I go back to check for new mail. This starts to optimize the process because if new mail arrives while I’m replying to other mail, as soon as I’m finished replying there is no wait state.

Looping Subprocess with Timer

Dealing with exceptional conditions in a subprocess is much easier to do than with straight-through linear flow. This is because you can place one or more exception handlers on the subprocess border. For example, I can catch an error condition if it occurs, but I’m not really expecting this to happen all the time. Or I can cause an alternate flow to occur when the activities don’t complete within a specified time period. Or, I can watch for all of the above conditions and deal with them accordingly. In contrast, the linear flowchart style diagram gets extremely complicated and difficult to read without the capability to “dynamically” create exception flow.

In a linear flowchart style, many conditional gateways or flows are used to check for current state. In the BPMN style, intermediate handler events are used on the subprocess border instead. In the following diagram I add a few layers that handle the exceptional conditions that could potentially occur. I’m not going to explicitly check for the errors all the time. It’s more of a passive monitoring for things that might occur.

Complex Nested Looping Subprocess with Error Handling

First I can receive the intermediate message labeled “cancel”. This is here because instead of watching for mail all day someone might give me a more meaningful way to spend my time. So maybe my boss sends me a message to go out for coffee or something. When this occurs I terminate this process and go do something else.

Next there is an intermediate event that catches any errors that might occur in my process. This error handler will catch anything that might occur on the check mail or reply to mail. Note that this is not necessarily a technical step geared toward the geek crowd. This gives me a “catch all” way of dealing with exceptional conditions, regardless of what the condition is. Most likely I’ll have to interrupt the normal pattern and do some improvising to get the process back on track. For example, one day someone plays mailbox baseball. For those of you who don’t know what this means, it’s when someone takes a baseball bat and smashed the box where I receive my mail. So I can’t receive mail. Sounds like an exceptional condition, right? I’m not planning for this specific event to happen, but anything can happen. So I don’t want to stop my process dead in its tracks just because I don’t have a way to deal with anything that might come up. The error handler is most likely a generic manual step.

Note the outer looping subprocess. This ensures that if an error condition occurs that I can easily jump back directly into a new instance of my inner loop, which is the main normal flow.

An finally, at 5 PM I’m going home, so I terminate the process. Because I’m a “clock puncher” type of person (How I wish this were true instead of me writing this post past midnight for three days now) it doesn’t matter what I’m doing. When the whistle blows at 5 PM (the timer event) I’m going home. Forget about replying, forget about checking for new mail.

So that’s the process. Now what would this same process look like if I didn’t have a subprocess and used upstream flow instead? Here is the equivalent diagram without using subprocesses, or should I say as close as you can get to the equivalent behavior.

Complex Upstream Flow with Error Handling

To achieve 100% of the same process flow behavior using upstream flow it’s incredibly difficult. In fact, this small example took several tries for me to get it right, and I’m still not totally convinced its the same. Feel free to comment and tell me how I did. The point is, when you start handling errors (as you should be doing in all processes anyway) in the upstream flow style, the diagram gets very complex to create, and even more difficult to read. Now just imagine this upstream flow example using swimlanes across multiple participants. You will probably end up with lines going all over the place and it’s a real eye sore to look at.

Just to put some context around this, all we are doing here is checking for mail and it’s already getting hard to read. Imagine if we were to model a real process! So for detailed process design including proper exception handling, the upstream flow doesn’t work so well.

Looping Subprocess Advantages:

• Explicit loop control
• Focus on a single process participant, which frequently yields a more accurate/detailed process diagram (see my other posting about swimlanes).
• Ability to easily deal with multiple exceptional conditions without complicating the normal flow.

Looping Subprocess Disadvantages:

• Slightly more difficult to understand for people that have not been trained on BPMN syntax. Note however that this can easily be explained to the BPMN newcomer in about two minutes, or you can just as easily add a text annotation to explain the loop.
• No way to determine what the loop condition is without annoations.

Style 3: Multiple Instance

Multiple Instance Subprocess

The multiple instance has two use cases. This sometimes happens in the BPMN specification. It’s not always clear in the diagram which use case is actually occuring. I suspect this will be cleared up in the 2.0 or later specification (or at least I hope so). Because of this current issue in the BPMN specification I recommend using a text annotation externally explain the sequence behavior. Note that the external text annotation is also a good practice for the looping subprocess as well.

Use case 1: Serial Execution

Use when you want to repeat some activities for a fixed number of times. There is no condition on breaking the loop. For example, “do this five times”. Each instance of the activity is performed in an iteration, meaning that each after the first iteration the subsequent iterations will not occur until the previous has completed. Essentially this is the same as the looping subprocess, except that there is no need to specify a condition that will cause the loop to break it’s loop. Only a number of iterations is provided.

Multiple Instance Serial Execution Mode

The same diagram can be expressed using only task shapes, but requires many more shapes to accomplish the same expression.

Multi Instance Serial Task Equivalent

Style expression for Serial Execution: Use in a “for each” loop when the number of iterations is known prior to execution. Not applicable to a “do while” or “do until”. Don’t use in any loop where a condition or normal flow might exist that would cause the loop to break before the number of iterations is complete. The usage of exception handlers is acceptable (and most often encouraged).

An important consideration for using this expression is whether or not you know in advance the number of iterations you will perform (If I am repeating myself here it must be because this is important). Otherwise you should use the looping subprocess instead. Conditions such as “do until the color is sufficient” or “keep checking the temperature every 5 minutes until the inner temperature is 200 degrees” is not a candidate for a multiple instance loop. Instead, a good example for a multiple instance loop is “Get 100 people to sign the petition”. Another example could be “take exactly 10 steps forward before turning left” if each step is an iteration of the looping activity. But then again, if you want to get very technical here one could argue that each step has a dependency on the other leg (left leg/right leg) to perform its duty, so this would disqualify the multiple instance for each step. Instead I could either hop 10 times or take 5 pairs of steps forward.

Use case 2: Parallel Execution

The basic use case is the similar to the serial execution use case, except that instead of iterations, X number of instances will instantly be launched, all running in parallel. Like the serial execution, there is no need to break the loop. In fact, it’s not really a loop at all. You are simply showing a different form of parallel flow in which you are launching X number of identical activities simultaneously.

Multiple Instance Parallel Mode

The same diagram using parallel gateway looks like this

Multiple instance parallel gateway equivalent

Style expression for parallel Execution: Another way to word this notation is “do something X number of times, right now, and don’t wait for anyone else to complete”. Use when you want to perform the same activity a fixed number of times, and each activity can be performed independent of the other with no dependencies of any other instances of the same activity to complete. Never use the parallel execution in situations where one activity might depend on another completing. Never use this expression when the activities in each instance might contain a different sub-sequence.

In the example above referring to “Get 100 people to sign the petition” we could apply the multiple instance. However, there is a subtle difference that occurs. We would have to get 100 people in action simultaneously. So in the serial execution example we are likely a single person going door to door for signatures. In the case of the parallel, it’s more likely that we blasted 100 emails out to people and we are awaiting 100 responses. So it might not be possible to actually receive 100 positive responses out of 100 emails sent unless the response is unanimous. Instead you might want to express that out of 1000 sent emails we want to count at least 100 positive responses, which causes a break of some sort. Normally I would suggest that you use the looping subprocess for this example. But in this case you have a unique problem that is very difficult to resolve with a normal loop; you have to correlate each response with the preceding request that is unique for each instance.

Looping Subprocess Emulating Parallel Multi-instance

It’s important to note that the serial execution and parallel execution appear identically in BPMN. According to the specification the execution mode is determined by the “attributes”. Now you see, this is what happens when a perfectly good modeling notation meddles in process automation and execution. I mentioned earlier that I hope this will be fixed in an upcoming version of BPMN. For example, vertical lines for parallel execution and horizontal lines for serial execution would have been nice. But the specification simply stops short of offering a graphical solution and suggests that execution engines use the “attributes” to specify behavior. This does nothing for creating a diagram. So I ask the folks at OMG to please fix this so that people who want to just create a diagram can have an easy way of doing so without having to read “attributes”. Now that I’ve vented my frustration on this subject, might I suggest for the rest of us to use a text annotation external to the subprocess to resolve the ambiguity (as in the “multiple instance parallel mode” example).

Multiple Instance (parallel) – Advantages:

• No need to specify a loop condition based on data. You can clearly tell that the activities will occur a fixed number of times, and this number of times is known before the loop begins.
• Has the ability to dynamically generate a bunch of parallel flows without having to draw all of them explicitly (parallel execution).

Multiple Instance (parallel) – Disadvantages:

• You cannot tell if this is a parallel or serial execution without any sort of annotations externally.
• You cannot tell exactly how many parallel instance or serial iterations are actually being performed. Again, to resolve this problem you should use external annotations.
• Hardest to understand, least documentation and examples in the BPMN 1.2 specification.

UML Specification:

Swimlane: a way to group activities performed by the same actor on an activity diagram or to group activities in a single thread.

The term swimlane appears for the first time in formal process modeling in the UML specification. First there was the activity diagram. Then there was a need to separate the activities of individual actors. The swimlane was born. So why are we using BPMN these days instead of UML? Well the answer is quite complicated. The UML specificaiton is full of other types of diagrams including class diagrams, state diagrams, interaction diagrams, and more. Most of the UML specification is very technical, therefore making it less than idea for most business uses.

Many people today believe that the term swimlane is part of BPMN. In a way, this is partially true because the BPMN specification says that both a pool and a lane are techinically a swimlane.

BPMN Specification :

UML was created in 1996. Remember 1996? Internet… What’s that? 1998 – Internet is pretty cool, and by 1999 my mother sent her first email. I recall in 2001 I heard someone say the word “blog” for the first time. In 2002 BPMN was born. And now what we have the history lesson out of the way…

• Pool: Defines activities designated for a single participant. Pay special attention to the words single participant.
• Lane: “A further subdivision of a pool”. Quoting from the BPMN 1.2 specification: “Lanes are used to organize and categorize activities”.

The BPMN specification says specifically that both pools and lanes are considered to be a swimlane. So this is where some of the confusion comes from. Technically it’s correct to call a BPMN pool or lane a swimlane, but the swimlane is not defined as part of the BPMN specification.

Here is an example of a UML style diagram using swimlanes:

UML Swimlane Style

This is a small process where a manager wants to hire someone. The manager submits a job requisition to human resources. HR returns a list of candidates and the manager interviews them. This cycle continues until a suitable candidate has been found. After a candidate has been found, accounting is notified to set up the payroll for the new employee. On the first day of work the manager conducts the initial briefing and gives the new employee a tour of the facilities.

The example diagram used the BPMN shapes but is actually a UML style diagram in terms of swimlanes. Often I see this style of diagram in BPM tools (not calling out any vendor specifically here). This diagram is actually incorrect according to both the UML and BPMN specifications. In UML the shapes and usage is slightly different than they are in BPMN. In BPMN you cannot have a lane without it being inside of a pool. I suppose one could argue that the entire diagram is the pool, in which case the only thing that is missing is the label for the pool. So we would have to assume that the pool has something to do with people.

Now let’s take a look at the corrected version of the diagram with a BPMN pool correctly displaying the lanes.

BPMN Pool with Lanes, single participant

In this example the pool is called People because that is the only logical assumption we can make regarding who the participants are. In fact, if you take the specification literally, there is only one person performing all of the activities. Remember that a pool is a container for activities associated to a single participant. In this respect it is not possible to transition from one person to another within a pool. Each additional participant requires another pool. The lane could be used to indicate that the activities are associated with a particular category of work. For example, the subprocess for finding candidates is actually a performed by the same person that creates the job requisition, but the category of activity is human resources. So I suppose we could say this participant role wears a lot of hats in their organization.

Often I see this style of diagram and I realize that the intent was to show that multiple people are involved in the process. However, this is incorrect in BPMN. If the intent is to show the multiple participants’ activities, you must draw them in multiple pools. But this creates another problem; I cannot draw a transition line (solid line) between pools. I must use a message. Why? First we have to understand what transition means.

• Transition: One activity from a participant has completed and another has begun. Transitions are notated with a single solid line with an arrow head pointing in the direction of the flow (sequence flow line). Sequence flow only occurs within the scope of a single participant.
• Interaction: A process participant wishes to involve other participants through messaging. Interaction is a form of communication that involves the sending of a message. Interactions are shown in BPMN with a single dashed line with an open arrow head indicating the direction of message flow.
• Message: A means to communication between process participants. A message has a well defined recipient and can have a message body containing process data or other data artifacts such as document attachments.

You can see from the definition that a transition is not allowed between participants. This is because it’s simply not possible. In any process, no matter if it’s human centric or system centric, any interaction between participants requires some sort of communication. Messaging is the the means in BPMN to have direct communication between participants. It is also possible to coordinate activities with things like signaling, but this is not actually an interaction. Signals (see my other post for details on signals) are used to coordinate events, but are not used to communicate.

So if you wanted to create a diagram that showed correct BPMN formatting, it would look like this:

BPMN Diagram with Pools and communication between participants

The pools for the Accounting and Human Resources participants are collapsed for simplicity. This is a common practice when you wish to show in your diagram the focus on one single participant, but you still wish to show the points in which this participant interacts with others. Most likely I don’t care to show the details of the accounting department because it’s outside my juristiction, and I have no visibility on what they actually do. Also, it’s better to let accounting manage their own processes.

The other concept of style that I’m including in this example is the looping subprocess instead of the “upstream flow” lines. Upstream flow is when you sequence an activity that has already occurred. This is almost like going back in time. The problem with going back in time is that I’m not actually going back in time here. Something is different. I have a new iteration of an activity, but I’m not redoing the exact same instance. In this example I am interviewing a new job candidate. I’m not interviewing the same job candidate again. So in some cases the upstream flow is acceptable, but only if you want to redo something. Otherwise the proper BPMN notation is to use a looping subprocess, which shows that a new iteration is required, and probably a new set of data input is also required. With this in mind you can see that it is impossible to have upstream flow between participants. Any time messaging is involved I highly recommend using a looping subprocess instead of upstream flow. Otherwise your process participants could be out of sync and you might never know it. This is especially important if you intend to make this process automated and executable.

Another important concept to note from this example is that I actually created a parallel flow without actually using a parallel gateway. This done through messaging. The first interaction with the Human Resources participant creates a blocking asynchronous message. This means that until I receive a response from HR I cannot do anything else in respect to this process. A message must be recieve before I can continue at the step “Receive HR Response”. However the second point of interaction is quite different. When I interact with the Accounting participant I don’t wait for a response. I am not showing in this diagram how long it takes for accounting to set up a payroll account. In fact, it might take longer than what it does for the new hire to start working. In the first two examples above the process showed that I actually cannot have the person start work until payroll is set up. This behavior occurs when two processes intersect.

Process intersection is a concept that is hard to understand so it deserves some attention here. In this small process example we have encountered a problem in just a few small activities. Imagine how complicated this would get if we actually draw the entire set of activies for the other participants. There is a way to avoid this overhead and still accurately depict your process diagram. But you must understand process intersection to determine where to stop drawing one diagram and start on another.

The answer to this problem is that we have two different processes. One is the process of hiring someone. Another process is the payroll setup, in which the hiring manager is the requestor, but the hirning manager is in no way in control of this process. Therefore when it comes to syncrhonizing activity between the manager and accounting it gets very difficult to draw from the manager perspective. It’s better to attack this problem from the accounting participant’s perspective, and show the manager as a secondary participant. You can additionally show escalations and notifications from the accounting perspective back to the manager, which resolves the problem of accountability for getting the job done. But what does this have to do with hiring someone? This is why I say it’s a process intersection, not an explicit interaction within the same process. Attempting to mix the two very different business objectives in the same diagram will lead to a very complicated flow that takes a BPMN expert to understand.

Now back to the 3rd diagram example. Because I’ve seperated out what accounting does by simply showing my interaction point, I can easily go forth with the current process and not have to worry about whether or not accounting has done their job or not. We are trying to show the steps a manager takes to hire someone. If accounting doesn’t do their job, the other diagram from the accounting perspective should notifiy the submitter (the manager) that the work has not been done by the due date. But this is out of scope here. Let’s assume it’s been done. Next all we have to do is wait until the day the new hire is supposed to be at work and conduct the first day activities. Plain, simple, understandable, and and from the perspective of the primary participant – the hiring manager.

Signal Event:

• Used for sending and receiving signals
• A signal is a generic, simple form of communication
  • Within pools (same participant)
  • Across pools (different participants)
  • Across Diagrams
• Has no specific recipient, meaning it could be received by any participant that is listening. (note that a participant could be a person, a system, or another process).
• The signal has a name
• Has attributes that further describe the signal
• Does not have a message body

Use case 1: Signal an unknown participant

Perhaps the most useful feature of the signal event is signaling an unknown participant. Often when I am in a store I hear an announcement “There is a car in the parking lot with its lights on”. Or sometimes I get an email asking “Who is working on the xxxx account?”. These are requests to get someone’s attention, but we don’t know specifically who the person it.

In the shopping mall example, we have a car with the lights on. The participants are the store(s) and the shoppers. We don’t know who’s car it is, so the announcement describes the car. So to model this in swimlanes, you would have these two participants. There are however a some problems with the swimlane appoach. First, you don’t know which of the shoppers the car belongs to. You must announce to every shopper. Second, you don’t even know if this is in fact a shopper that owns the car. The car could be owned by an employee, or it could be a shopper in another store. So the actual participant in this case is anyone that might potentially park a car in the store parking lot (potential car parkers).

An announcement for a car in the parking lot with its lights on

The signal event is also limited by the attributes “Black”, “BMW”, “Plate Number x12345″. So if I don’t have a black car I immediately ignore the rest of the message. Or if I have a black car but it’s not a BMW I can ignore this message. But if you have a black BMW and you don’t know what your plate number is, I’m assuming that you probably have some kind of subprocess for this. The point is, it is the responsibility of the potential signal receiver to identify its self and act accrdingly. Nobody is going to make you go turn off your lights. From the perspective of the store, they have fulfilled their obligation by making the announcement.

Note the usage of the group artifact shape (dash-dot-dash box around the signal events). This is used solely for style purposes and is not required according to the BPMN specification. Personally I have found it to be helpful when reading diagrams, similar to how punctuation makes it easier to read text. Case in point, if you notice the example below, it does not have the group artifiact shape around the signals. Your eyes must wander the diagram to find the matching signal receiver.

In the email example where someone is asking who is working on a particular account, again the signal is intended for anyone who might respond. We have potentially an account manager participant, or maybe it’s a customer service participant who gets a call from a customer but doesn’t know who the account manger is. In this case there is a message event (the email) but not necessarily. If the address is sent to a disribution list such as “all-account-managers” then this is more like a signal event than a message event. Yes, it is in fact an email message. It might even have a body attached. But who really reads these broadcast emails anyway? If you are like me you get 200 emails a day (on a slow day). I read the subject line and if it’s not interesting it goes straight in the trash. If someone is not smart enough to put the account number in the subject line which makes me actually read the message it’s not as efficient. So in the following example diagram we cover both cases, where the subject contains the signal attributes and the other case where I have to actually read the message.

Signal sent to find out who is responsible for an account

In theory you could use either a message event or a signal event for this example. The differenciation in this case is the fact that the sender participant might receive a response, but might not. The message body is probably empty in this case and the subject line might read “Who owns account number A12345″. If this isn’t my account I’ll delete the email it without reading it. Othewise I might want to do something before the customer becomes upset with me. The signal event simplifies this diagram because if I were to use a message event instead, I would also need several shapes to “filter” the message data to determine if it’s mine or not. Hence, the “is it for me?” gateway, which covers the case where someone didn’t bother to but the account number in the subject line and forced me to read the message. But if I know for a fact that all signals of this type will have the account number in the subject line, this is a true signal event and I don’t needt o evaluate if this is for me or not. This is because a signal event has an implicit filtering built-in. The inteneded process participant(s) must know their responsibility for receiving the message.

For persons not familiar with the notation, I chose to use an event driven gateway (the pentagon symbol insde the diamond) with two potential solutions to the problem of who owns the acocunt. In one case, someone will respond within a reasonable amount of time. In the other case, after a period of time has elapsed, I’m not going to wait any longer and take care of the custmomer myself.

Use case 2: Subscription

One good example I can think of for subscription is Twitter http://www.twitter.com . Email distribution lists are on the border line between what is a message and what is a signal. To qualify a form of communication to be a signal, it must be simple. Emails can contain large amounts of text, so they are not simple. Twitter is a site that allows you to broadcast some text (up to 140 characters maximum) to the world. Being that the messages are limited in size, they must be simple. To receive “tweets” (the broadcasts) on this site, you must subscribe to it. With no subscriptions, the “tweet” goes nowhere. Often the “tweet” goes out to everyone even though the message might be intended for just a few people. So again, the participant(s) must identify themselves and determine if the information is useful and relavant to their current process instances. In contrast, if I were to send you an email instead of broadcasting a tweet, this would indicate that I want specifically you to read it.

Another example of subscription is a stock symbol monitor. Stock prices are streamed over the internet. You can subscribe to specific events. For example I want to know ABC corp’s price. If I want to start receiving stock quotes, I simple “turn on” that stock symbol and the events will continue to stream until I turn it off. Whenever the stock market is open, the stock streamer simply sends the quotes, and doesn’t care if anyone is receiving them or not. Every stock symbol that has a price change will cause an signal event.

Signal event name: Stock Quote

Attributes: Up or Down, Price

Use case 3: Synchronization

In a large process with many participants, some processes require that some activities run in parallel, but must also be synchronized. For example, a procurement process where someone asks for some money but simultaneously starts to seek out a vendor. The vendor can be selected but the order cannot be placed until the funds have been acquired and transferred into the appropriate account. Let’s say that the vendor selection is handled by a special group of people. Being that it’s a group of people the originator might not know who exactly is working with the vendor(s). The order will not be processed until the signal to proceed has been sent. I might want to know about the status of the process as it progresses, but I don’t really need to know the full details.

I chose to use a signal event in this example for one specific reason: There are persons involved that were not introduced and potentially have no knowledge of each other. For example, the funds manager processes the request to transfer the money. Because the order manager is interested in this process instance, they can now proceed with the order placement. There is nothing in this process that says that the funds manager and the order manager are specifically aware of each other. They are in different departments and potentially these are different processes entirely. The only thing tying the process together is a common communication channel of some kind that has the ability to broadcast messages.

Synchronization accross multiple participants

In this example the loading dock receives a package. For the sake of argument, let’s say that the loading dock maintains a simple website that shows a tracking number and a date when it was received. If the Originator participant does not read this website regularly (the subscribe) then the package will remain in the receiving department indefinitely. It is in the interest of the originator participant to regularly monitor the status page to receive timely updates. Eventually the loading dock will delete the old messages. So if I don’t actively monitor the status page, I might not ever know the package was received.

Use case 4: Interruption

Interruption involves stopping multiple participants from performing their current activities, most likely because a major event has occurred that requires the process flow to change significantly. A simple example of this is when a customer is requesting a home mortgage loan. Mortgages are a complex process that requires many items on on checklist to be completed by multiple participants. Let’s say that the customer changes their mind and decides that now is not a good time to buy a home. Suddenly we have 10 people doing things for a process instance that no longer exists. We don’t want anyone to continue working on this process instance because it would be a waste of time. So a signal is sent, which would cause all interested participants to stop working on this loan.

Signal Event Name: Stop Processing

Attributes: Loan Number, Reason

Hopefully this post will help reveal the difference between a signal and a message.

Questions? Feel free to contact me.