A frequent complaint about BPMN is that it cannot adequately describe many common business process scenarios, particularly when all possible flow paths are not known in advance.  Actually, it can handle a good number of those, but many fall into a “gray area” – patterns that may or may not be technically allowed, depending on your interpretation of the spec.  One of those scenarios concerns variant forms of an activity.  If activity A has only two or three variants, the modeling is straightforward:  You just have a gateway that branches to variant X, variant Y, and variant Z, each shown explicitly as a separate activity in the diagram.  But what if there are dozens of variants?  For example, consider a nationwide insurance carrier that must conform to differences in each state.  You could have a gateway with 50 branches, but I don’t think many people would consider that a satisfactory solution. I sure wouldn’t.

Instead, you’d like is to say the next step is some variant of activity A determined by a variable (data object).  I propose that a Call Activity can do this, as long as all of the variants have the same set of inputs and outputs.  Some of you may say, of course, who would think otherwise?  But technically it is a gray area.  It is not explicitly discussed in the spec, but I believe it is allowed by the BPMN 2.0 metamodel and narrative text, although there is a small issue with the schema.

The spec says the Call Activity invokes a particular callable element, either a process or global task.  A definition of the callable element is external to the calling process definition.  The only requirement of the metamodel and spec text is that the Call Activity’s ioSpecification element must match the data inputs and outputs of the callable element.  So as long as all the variants of activity A are defined with the same set of inputs and outputs (even if some are not used), the metamodel would seem to allow a Call Activity to invoke one of the variants determined at runtime in the calling process instance.

The schema is a slight problem, since the Call Activity’s calledElementRef attribute technically is an id prefixed with the namespace of the callable element.  In other words, the schema implies it is fixed at design time, not settable at runtime.  You could resolve this by saying that the calledElementRef is an expression that resolves to a prefixed id.  There are other examples where an attribute dynamically defined as an expression of runtime data would add flexibility over the static design-time value technically required by the schema, such as a duration or dateTime value of a Timer event.  In non-executable models it is quite common to use a Timer event label that implies a dynamic value, and I believe that many BPM Suites can handle such dynamic values in execution.

I think this is a case where the schema is imposing a constraint that is not explicitly stated in the spec text or metamodel.  For the Timer event example, it’s not an issue for models conforming to the Descriptive or Analytic subclass, since only the label (@name) is serialized in the XML.  But it is a problem for the dynamically called activity example.  It would be better if BPMN 2.1 changed the data type of the calledElementRef from QName to a new named type that is essentially an expression that resolves to a prefixed id. 

[Note: using QName in the specific way that BPMN 2.0 does does not comport with the definition of the QName datatype anyway, so this would be killing two birds with one stone.]

There are numerous other ways in which dynamic and ad-hoc behavior can be modeled in BPMN 2.0, without resorting to CMMN or other initiatives that may or may not ever get traction.  If you are interested in this topic, check out my BPMN Master Class in June, where this will be a focus of discussion.