In every process there are decision points. Conditions can be proved by the process engine by evaluating formulars defined on conditional sequence flows. So the corresponding parameters must be set within processing the task before (diagramm taken from discussion post of Keith Swenson).
We have learned that in the most cases the user should decide during forwarding the business case to the next task. So we are offering the user the decision as items in the context menu of the marked business case in his inbox. For getting these menu items the process analyst can model this as follows (diagram was created using Signavio):
This seems to be BPMN 2.0 conform, but this isn´t. Conform is not to use a gateway but the use of two conditional sequence flows. The problem is that the menu items “approve” and “reject” are defined in the BPMN attribute “Condition Expression”. But how should the process engine know whether to produce menu items or to only evulate that expression after the forwarding request of the user? Our solution was to take another SAPERION specific attribute “Manual” which has to be checked for offering the expression entry as menu items.
Keith Swenson has missed this human decision handling last year and has proposed another solution in his post Representing Choice in a Process Diagram:
His idea was to offer a new empty attachable event. The label on the outgoing sequence flow could then be used for offering the menu item, in this case “hire” and “fire”. When I read this I was happy with it. But another BPMN expert, Bruce Silver, has stated in his post Keith’s Choice that attached events are no good solution. They show the unusual leaving of a task, which isn´t the case with this manual decision.
The proposal of Bruce was, that BPMN should offer another type of sequence flow with an own symbol on the beginning of its shape.
But what a pitty: nothing to see in the current beta version of 2.0. So we want to reactivate this proposal to become more BPMN conform in future!