Bruce Mayfield posts a comment on an old thread exploring different ways to model business exceptions in BPMN.  Since that original post I’ve worked out some best practices for different types of exceptions (business exceptions vs system faults, exception detected interanlly to the process vs signaled by external event, etc).  As a reminder that our BPMN training is now available from bpmessentials.com, it’s worth reprinting his comment here and showing the solution.  He writes:

… I have been trying to model a new system in the government sector. We are building an automated system to verify new employers have workers’ compensation insurance. Each day a new list of potential uninsured employers will be created, checked against another database to make sure a letter has not already been sent, and if a letter has not been sent, a letter will be generated and sent. We have identified that there will be the possiblity that there will be exceptions where the automated process is ” not sure’ whether to send a letter and will require review by a human to make a decision as to whether the letter should be generated and sent. In this context we consider this a different kind of exception process not related to an error that will terminate a flow but will result in a decision to flow a token down one of two different paths….

In this case, it’s not clear whether the “exception” is that the letter has or has not previously been sent.  But in this case it doesn’t matter.  This is a case of a business exception (not system fault) detected internally by task or process logic (i.e. not signalled by external event).  For that, we recommend use a gateway.  In fact, here this exception occurs twice, once following the automated check (DB lookup) and again following the human review, if required.

foreach.png

 

Here the whole subprocess is marked as a multi-instance loop (the parallel bars at the bottom), which BPMN uses to model ForEach looping as in Bruce’s example.