Business Process Model and Notation Avatar
  1. OMG Specification

Business Process Model and Notation — Open Issues

  • Acronym: BPMN
  • Issues Count: 8
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

fairly basic errors in some of your example flows

  • Key: BPMN21-440
  • Status: open  
  • Source: Ealing Council ( Louise McDonagh)
  • Summary:

    I have just started going through the 'Business Process Model and Notation, v2.0' document and come across some fairly basic errors in some of your example flows. On the one hand BPMN is very prescriptive, yet in the execution of the examples it is extremely lax and erroneous. I have not got very far into the document yet as it very heavy going, but 2 cases in point where your examples are poor: figure 7.1, 'Approve or Reject Policy' should be two mutually exclusive processes, one to reject and the other to approve, which should have 2 separate outcomes. If you are wishing just to show a high level articulation of this dependency, then the process should be phrased as 'Make Policy Application [Request] Decison'. The other process that jumps out as logically unsound is figure 7.3, example of collaboration process. There are 2 swimlanes, one for patient and one for doctor surgery. 'receive medicine request' is a 'pharmacy' function so should be in a '!
    pharmacy' pool. The way this process flows, there is no point in issuing a prescription request to the patient whose only duty is to present it back to the same surgery. Prescriptions requests have to go to a pharmacy, not the doctor. If the notation is being so prescriptive and requiring accurate conformance, the the examples need to be sensible, clear and error-free or there can be no confidence in the notation.

  • Reported: BPMN 2.0.1 — Fri, 28 Jan 2022 16:02 GMT
  • Updated: Fri, 28 Jan 2022 16:06 GMT

Description for "Mutiple Instances" is not correct.

  • Key: BPMN21-439
  • Status: open   Implementation work Blocked
  • Source: Oracle (Colombia) ( Carlos Alfredo Biscione Vecino)
  • Summary:

    On the referred chapter/section/table/page, the description cell for the item "Multiple Instances" must describe and differentiate sequential multiple instances and parallel multiple instances. The text in this table´s cell says the same for both sequential and parallel multiple instances, as shown (i enclosed the error within double brackets):
    " The attributes of Tasks and Sub-Processes will determine if they are repeated or performed once (see page 190).
    A set of three horizontal lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see upper figure to the right).
    A set of three vertical lines will be displayed at the bottom-center of the activity for [[sequential]] Multi-Instances (see lower figure to the right).".
    The description for the round box with vertical lines should read "parallel" instead of "sequential".

    Thanks in advance.
    Carlos Biscione - Oracle Colombia.

  • Reported: BPMN 2.0.1 — Thu, 27 Jan 2022 01:46 GMT
  • Updated: Fri, 28 Jan 2022 16:05 GMT

Typos - Incorrect internal references/pointers

  • Key: BPMN21-414
  • Status: open  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    (1) On page 204, the last sentence reads:
    The DataObject element inherits the attributes and model associations of FlowElement (see Table 8.44) and ItemAwareElement (Table 10.52). Table 10.54 presents the additional attributes of the DataObject element.

    However, the first Table reference should be to Table 10.51 (not 10.52), and the second should be to 10.52 (not 10.54).

    (2) On page 205, the first full sentence (not in a table) reads:
    The Data Object Reference element inherits the attributes and model associations of ItemAwareElement (Table 10.52) and FlowElement (see Table 8.44). Table 10.53 presents the additional attributes of the Data Object Reference element.

    However, the first Table reference should be to Table 10.51 (not 10.52). The reference to Table 10.53 is correct.

  • Reported: BPMN 2.0.1 — Mon, 16 Jul 2018 15:50 GMT
  • Updated: Tue, 7 Aug 2018 14:07 GMT

Allowable start events for event sub-process inconsistently defined

  • Key: BPMN21-359
  • Legacy Issue Number: 19166
  • Status: open  
  • Source: ( Devin Fensterheim)
  • Summary:

    There is an apparent conflict in the specification concerning the permissible Start Event types for an Event Sub-Process.

    On Page 174, the specification states: "The Start Event of an Event Sub-Process MUST have a defined trigger. The Start Event trigger (EventDefinition) MUST be from the following types: Message, Error, Escalation, Compensation, Conditional, Signal, and Multiple." This enumeration excludes the Timer and Parallel event types.

    This specification appears inconsistent with the restriction on Page 241, which additionally allows Timer and Parallel event types for the Start Event: "A Start Event can also initiate an inline Event Sub-Process (see page 174). In that case, the same Event types as for boundary Events are allowed (see Table 10.86), namely: Message, Timer, Escalation, Error, Compensation, Conditional, Signal, Multiple, and Parallel."

    It is consequently unclear whether Timer and Parallel events may be the Start Event in an Event Sub-Process.

  • Reported: BPMN 2.0.1 — Mon, 23 Dec 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

References to invalid sub clauses (incorrect sub clause numbers)

  • Key: BPMN21-358
  • Legacy Issue Number: 19092
  • Status: open  
  • Source: RealDolmen NV ( Steve van den Buys)
  • Summary:

    In chapter 2, sub clause 2.1, page 1 it is written that "Process Modeling Conformance type SHALL comply with all of the requirements set forth in sub clause 2.1". However, the requirements are set forth in sub clause 2.2. Also, the sentences after that refer to sub clauses 2.2, 2.3 and 2.4 but these should refer to 2.3, 2.4 and 2.5.

    In short: references to the requirements for the different conformance types should be to 2.2, 2.3, 2.4 and 2.5 and not 2.1, 2.2, 2.3 and 2.4.

  • Reported: BPMN 2.0.1 — Mon, 18 Nov 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Invalid use of MAY NOT keyword

  • Key: BPMN21-361
  • Legacy Issue Number: 19196
  • Status: open  
  • Source: ( Frank Munkert)
  • Summary:

    In several occasions, the BPMN 2.0.1 specification uses the keywords "MAY NOT". This keywords, however, are not valid according to RFC 2119.

    Probably "MUST NOT" would be correct. (Please note: the opposite of "MAY" is not "MAY NOT"!)

  • Reported: BPMN 2.0.1 — Tue, 28 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong sub clauses are referenced

  • Key: BPMN21-360
  • Legacy Issue Number: 19176
  • Status: open  
  • Source: ( Jonas Geißer)
  • Summary:

    Version 2.0.1 is still referring to the sub clauses 2.1-2.4 (as in Version 2.0) even though they have changed to 2.2-2.5

  • Reported: BPMN 2.0.1 — Tue, 7 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Suspected definition error in DataObject.isCollection

  • Key: BPMN21-357
  • Legacy Issue Number: 19083
  • Status: open  
  • Source: Atom Software Pty Ltd ( Paul Hopkins)
  • Summary:

    In Table 10.52 the description of DataObject.IsCollection reads "If an itemDefinition is referenced, then this attribute MUST have the same value as the IsCollection attribute of the referenced itemDefinition".

    This description prevents BPMN from defining a collection of DataObjects on a single Item Aware Element referred to by an Item Definition. Therefore, if I wish to model an individual item X and a collection of item X they need to reference different item definitions - surely this is not the intent.

    I propose rewording this sentence to read "If a referenced itemDefinitions isCollection attribute is set to true, then this attribute MUST also be set to true".

    I don't know if there is a flow-on effect to other areas of the documentation.

  • Reported: BPMN 2.0.1 — Thu, 14 Nov 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT