Keith Swenson has a nice post on the representation of human choice in BPMN. He objects to the use of a gateway to represent a human decision at the end of a task, like clicking either Approve or Reject. Instead he proposes a new boundary event for this purpose (he suggests the None boundary event, currently not used in BPMN). He raises some good points, and the comment thread generally agrees with him, but on balance I don't agree. Here's why.
BPMN constantly has to balance expressiveness and complexity, while maintaining some measure of consistency in the metamodel. Compared with other modeling notations, BPMN is notable for its expressiveness - ability to distinguish in the diagram fine differences in meaning - and has been rightfully criticized for the notation's resulting complexity. So there is a "cost" to adding any new shape or variant of a shape, such as Keith is proposing. I am not in principle against enlarging the notation; I've proposed several additions myself. It's just that there must be a good reason why the existing notation is inadequate.
Keith is fine with the following:
... but he objects to this:
What's the difference? To BPMN, there is none. A gateway does not perform work. It has no "performer." It just directs the flow down this path or that based on evaluating a data expression. Keith is fine with the first one, because the item to be purchased is implicitly a data element of the process. For some reason, however, he does not consider the hiring decision variable to be such an implicit element. I can sympathize with his logic, but I disagree.
The hallmark of what I call "Level 2" modeling is going along with BPMN's hidden assumptions, of which there are many. A big one is that even for processes that are not automated in a BPMS, the notation acts as if it is. This should not be an issue for Keith, because Fujitsu also assumes a BPMS. Apparently Fujitsu's process engine does not implement human choice by populating a variable with an enumerated value and testing it in the routing logic, but I would surmise that most BPMS's do it that way. In any case, this mechanism is a hidden assumption of BPMN., built into the semantics of gateways.
Keith suggests instead something like this, because it more directly connects the user's decision to the subsequent flow:
Well, it does, but it has other issues. On the consistency side, a boundary event on a task implies the task completed "abnormally." In fact, here there is no "normal flow" exit from the task, just two exception flows. This is not technically illegal, but I would maintain it is inconsistent with the usual semantics of boundary events on tasks.
This is mostly about methodology and style, which I have come to see is really at the heart of using BPMN effectively. (Hence, my upcoming book, BPMN Method and Style...) The letter of the law, as stated in the BPMN spec, allows inconsistency in the notation, but it is better if you apply principles consistently throughout.
In my method and style, a gateway following a task that completes normally is usually testing the end state of the task, as in the human decision example. But it could be simply testing a property of the instance, as in the first example. A boundary event on a task, whether message, timer, or error, means the task was interrupted before it completed normally. That is, it does not imply a normal end state of the task. That is not what Keith intends in his proposal, and thus I believe it is inconsistent with the rest of BPMN.
Even if you still like the boundary event for this, is a new None boundary event the way to go? BPMN 2.0 provides a new event type, Escalation, which on a user task boundary implies an ad hoc user decision in the middle of a task. It is normally non-interrupting, meaning the task continues in parallel with the exception flow, but it could be drawn as interrupting, and I suppose one could interpret this as a "human decision" at the end of the task. But to me at least, it implies an exception, not normal completion. So I just don't think a boundary event is consistent with the rest of BPMN if the intent is to describe one of N possible branches that could be taken following normal completion of the task.