How to model cancellation of process by user in BPMN2?

Question

I am modeling the process of handling applications. In real life the process is like this:

• Data Entry person takes email (submittal) from mailbox and see if this valid application form or spam / junk email
  • If that is valid form, she will create application object in a system and start entering data from form
  • As she works through form (it is large) she may save "application" and return to it later
  • When all data is entered she will submit application
  • After application is submitted few more actions needs to be performed - some files need to be collected and attached to application
  • At the end it is send to QA for checking, etc.

The thing is that at any time Data Entry person may click on "Withdraw" in existing system and application will be withdrawn (cancelled).

How this should be modeled using BPMN2?

Answer 1

• Bundle all tasks that you need to withdraw within a subproces.
• Place a boundery event on the tasks that have a withdraw action and route this to a cancel exit event within the subproces.
• Place a boundery cancel event on the subproces in which you handle all cancelation activities.

This is know as modeling an ACID transaction in BPMN2, which is short for:

• Atomic, as in: all or nothing.
• Consistent, as in: prevent that the system state will be inconsistent.
• Isolated, as in: each instantiation of the process is handled without any influence of an other instantiation.
• Durable, as in: the state of the process is persisted in the database, so it can be restored when the system crashes.

Answer 2

When I read above answers I can only say: I couldn't agree more.

On the other hand I agree also with the comment that it would be nice to see a diagram that visualizes these answers.

Here you are:

The diagram is based on some interesting reference web page bpm - design patterns. In particular, please find the design pattern 25 - Cancel Region.

I believe that it is what you've asked for.

Answer 3

Model it as a Withdraw path, leading to an exit state. Among other things, you want to collect information on amount of time spent on the task until withdrawing, reason for withdrawing, frequency of withdrawing, rate of withdrawal per data entry person, etc.

All of the statistics may not be obvious right now, but designing for future analytics isn't always a waste of time.

Edit:

To model this on the diagram, when you have many steps, use a sub-diagram to hold the main process and on the main diagram, show a single exit path to represent the withdrawal.