Business Process Model and Notation Avatar
  1. OMG Specification

Business Process Model and Notation — All Issues

  • Acronym: BPMN
  • Issues Count: 42
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
BPMN21-443 Ad-Hoc Sub-Process falsely listed as BPMN 2.0.2 open
BPMN2-318 Mistake in Table 7.2 BPMN 2.0.2 open
BPMN21-437 No correct validation rules mentioned BPMN 2.0.2 open
BPMN21-436 Clarify the possible catchers of error and escalation events BPMN 2.0.2 open
BPMN21-435 wrong word for parallel multi instance in description BPMN 2.0.2 open
BPMN21-433 All None Start Events should get a token at instantiation, if the Top-level Process or Global Process (or even Sub-Process) contains multiple Non Start Events BPMN 2.0.2 open
BPMN21-432 Confusing definition of LinkEventDefinition's fields "sources" and "target" BPMN 2.0.2 open
BPMN21-427 Please clarify if the usage of a XOR Join is not redundant BPMN 2.0.2 open
BPMN21-426 Is there a definite reason to exist for a XOR join gateway? BPMN 2.0.2 open
BPMN2-317 Event list seems to be not complete BPMN 2.0.2 open
BPMN2-316 Misprint in call activity view BPMN 2.0.2 open
BPMN2-315 Different explanation and example. BPMN 2.0.2 open
BPMN21-425 Example uses invalid DI attributes and wrong namespaces BPMN 2.0.2 open
BPMN21-421 "Flow Object" should be "Flow Node" BPMN 2.0.2 open
BPMN21-420 Typo: BPMN 2.0.2 open
BPMN21-419 Typo in example BPMN 2.0.2 open
BPMN21-418 Diagram 8.1 looks amateurish BPMN 2.0.2 open
BPMN21-417 Wrong sub-section reference numbers BPMN 2.0.2 open
BPMN21-415 Inconsistent BPMNShape Attributes in tables BPMN 2.0.2 open
BPMN21-413 Inconsistent semantics of multiple none start events BPMN 2.0.2 open
BPMN21-412 Attribute called BPMN 2.0.2 open
BPMN21-411 Relationship relates CMOF::Element, not Artifact BPMN 2.0.2 open
BPMN21-410 Unclear how to add new Artifact Types BPMN 2.0.2 open
BPMN21-409 Derivation of categorizedFlowElements is only given by visual nesting BPMN 2.0.2 open
BPMN21-408 Some of the descriptions in the bpmnElement column of the table are incorrect BPMN 2.0.2 open
BPMN21-406 Add start and intermediate events of type "User" BPMN 2.0.2 open
BPMN21-405 Outgoing sequence flows from event gateways should allow conditional expressions BPMN 2.0.2 open
BPMN21-403 Probable contradiction: Implicit compensation and Throwing Compensation Events BPMN 2.0.2 open
BPMN21-404 Define "Cancellation" more precisely BPMN 2.0.2 open
BPMN21-402 Intermediate Compensation Events can have outgoing Sequence Flows BPMN 2.0.2 open
BPMN12-35 Execution semantics of Activity with conditional outgoing Sequence Flows BPMN 2.0.2 open
BPMN21-400 p.172 Reference pointing to wrong figure, p.174/175 Event marker missing in figure BPMN 2.0.2 open
BPMN21-399 Inconsistent default value of dataStore/@isUnlimited BPMN 2.0.2 open
BPMN21-398 Clarification needed regarding converging exclusive gateway and slash marker BPMN 2.0.2 open
BPMN21-397 Task Description -- Internal Conflict BPMN 2.0.2 open
BPMN21-394 data storage element is missing in overview BPMN 2.0.2 open
BPMN21-393 Confusion over dataOutput attributes BPMN 2.0.2 open
BPMN21-389 Wrong table reference number BPMN 2.0.2 open
BPMN21-369 Missing event marker in Figure 10.30 BPMN 2.0.2 open
BPMN21-366 Section 10.3.4 Human Performer is not peorperly defined for implementation interpretation BPMN 2.0.2 open
BPMN21-374 Second occurance of sequential Multi-Instances should be parallel BPMN 2.0.2 open
BPMN21-373 Use of per mille symbol unclear (‰) BPMN 2.0.2 open

Issues Descriptions

Ad-Hoc Sub-Process falsely listed as

  • Key: BPMN21-443
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    There is a list of non-operational elements in the introduction to the section *13. BPMN Execution Semantics. The Ad-Hoc Process is in the list. However, in chapter **13.3.5 Ad-Hoc Sub-Process* its execution semantics is described in detail. So, I think the "details needed to execute them on an engine" are given. It seems, the Ad-Hoc Sub-Process is in fact operational and should be removed from the list.

    PS: There is no "Ad-Hoc Process". The "Sub-" is missing.

  • Reported: BPMN 2.0.2 — Thu, 15 Feb 2024 10:09 GMT
  • Updated: Thu, 15 Feb 2024 19:40 GMT

Mistake in Table 7.2

  • Key: BPMN2-318
  • Status: open  
  • Source: - ( Sebastian Handwerker)
  • Summary:

    I found a mistake in the BPMN 2.0.2 specification.

    https://www.omg.org/spec/BPMN/2.0.2/PDF

    On Page 37:

    "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 second "sequential" is wrong. The vertical lines are for PARALLEL Multi-Instances.

    The corrected form is the following:

    "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 PARALLEL Multi-Instances (see lower figure to the right)."

  • Reported: BPMN 2.0.2 — Mon, 2 May 2022 20:54 GMT
  • Updated: Tue, 3 May 2022 16:55 GMT

No correct validation rules mentioned

  • Key: BPMN21-437
  • Status: open  
  • Source: BBW ( Dieter Proost)
  • Summary:

    Dear Team

    On the provider www.bpmn.io I can create a flow that is exportable to a .BPMN/XML file. In order to check this XML validation the library links to:

    <?xml version="1.0" encoding="UTF-8"?>
    <bpmn:definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" xmlns:di="http://www.omg.org/spec/DD/20100524/DI" id="Definitions_13r4fun" targetNamespace="http://bpmn.io/schema/bpmn" exporter="bpmn-js (https://demo.bpmn.io)" exporterVersion="8.8.0">

    The URLS to Omg.org are giving a page 404.

    Question:
    Is it possible to support me the correct Omg URLs for the XML header? so the XML can be validated

    Kind regards

    Dieter Proost

  • Reported: BPMN 2.0.2 — Wed, 20 Oct 2021 08:17 GMT
  • Updated: Wed, 3 Nov 2021 16:11 GMT

Clarify the possible catchers of error and escalation events

  • Key: BPMN21-436
  • Status: open   Implementation work Blocked
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    I always took for granted, that error and escalation events can only be catched in the same process instance at the same or a higher level as the throw event. A recent discussion in the OCEB group revealed, that the specification doesn't really support that view, without some reading between the lines.

    The semantics of these important events should not be open to debate. I suggest to add a clarification.

  • Reported: BPMN 2.0.2 — Wed, 18 Aug 2021 13:02 GMT
  • Updated: Fri, 20 Aug 2021 14:18 GMT

wrong word for parallel multi instance in description

  • Key: BPMN21-435
  • Status: open  
  • Source: None ( Jan Ruhstrat)
  • Summary:

    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).

    Above the description of the multi instances from the document.
    In the last sentence the parallel multi instance ist described. But instead of using the word parallel its sequential.

    Best regards, Jan

  • Reported: BPMN 2.0.2 — Sun, 15 Aug 2021 22:53 GMT
  • Updated: Mon, 16 Aug 2021 14:19 GMT

All None Start Events should get a token at instantiation, if the Top-level Process or Global Process (or even Sub-Process) contains multiple Non Start Events

  • Key: BPMN21-433
  • Status: open   Implementation work Blocked
  • Source: TU Berlin ( Kai Grunert)
  • Summary:

    Section 10.5.2 on page 238 states:

    If the Process is used as a global Process (a callable Process that can be invoked from Call Activities of other Processes) and there are multiple None Start Events, then when flow is transferred from the parent Process to the global Process, only one of the global Process’s Start Events will be triggered. The targetRef attribute of a Sequence Flow incoming to the Call Activity object can be extended to identify the appropriate Start Event.

    1. Bug: the text only mentions "Global" processes and not "Top-level" processes, which is another but similar category of processes (p. 239). I find no semantic definition about multiple None Start Events in Top-level processes. I think, it should be the same semantic as for Global processes.

    2. Bug:

    As already mentioned in Bug report BPMN21-413 (https://issues.omg.org/issues/BPMN21-413) there is a semantic inconsistency with the definition of the process instantiation (also Section 10.5.2 on page 238):

    All Flow Objects that do not have an incoming Sequence Flow (i.e., are not a target of a Sequence Flow) SHALL be instantiated when the Process is instantiated.

    To bring both text passages together, I assume the term "Flow Objects" refers more likely to "Activities", because multiple start events are usually handled in an exclusive manner (defined at multiple places in the specification).
    *But, in my mind there is no semantic difference between an Activity A with no incoming sequence flow and Activity A connected to a None Start Event.* (This just seems to be a modelling preference.)
    So, the question is, how to handle multiple None Start Events in a Global and Top-level process? Exclusive (like the other typed start events) or Inclusive (like Activities without an incoming sequence flow) semantics?

    Solution:

    To stay consistent (no semantic difference between an Activity with or without a None Start Event), I plead for the inclusive semantic, i.e. to put a token into every None Start Event if the process was instantiated via a None Start Event.
    If the process is instantiated via a typed start event, the exclusive semantic should remain.

    Additionally, this is more user-friendly from a modeling perspective than the alternative: if Start Events have to be used (maybe because of a modeling guideline), the parallel semantic would require to have one None Start Event connected to a Parallel Gateway connected to all parallel-executable Activities. This could look very messy compared to one None Start Event at each Activity.

    The disadvantage is the difficulty to model/implement the exclusive start if it is needed. In my experience I have rarely seen it and the inclusive start is way more often required for multiple None Start Events.
    But let's look into that: For a Global (callable) process you can still use the existing targetRef attribute on the incoming sequence flow to refer to/instantiate just one None Start Event.
    None Start Events are also typically used for a manual process start in a process automation engine. If it is really intended to just put a token into one specific None Start Event, you could alternatively 1. use a Message Start Event or 2. the process engine can offer a way to just start a specific None Start Event.

    3. Related Improvement:

    If the semantic will be defined as suggested in Bug 2 for multiple None Start Events, it is also possible and useful to allow multiple None Start Events in embedded Sub-Processes. The entry into the Sub-Process would put a token into every existing None Start Event.

  • Reported: BPMN 2.0.2 — Wed, 27 Jan 2021 16:43 GMT
  • Updated: Fri, 29 Jan 2021 17:57 GMT

Confusing definition of LinkEventDefinition's fields "sources" and "target"

  • Key: BPMN21-432
  • Status: open  
  • Source: signavio.com ( Philipp Maschke)
  • Summary:

    We recently had a dispute with a customer, who wanted to use a different BPMN tool for downstream processing of certain process models exported from our tool.
    While analysing their claim, I found confusing definitions for the LinkEventDefinition:

    The textual specification for the LinkEventDefinition (and especially the table 10.98) defines three additional fields (compared to the EventDefinition): name, sources and target. All three are listed in the table 10.98 as "attributes":

    However, the following XSD definition actually specifies only the name to be an XML attribute while target and sources are defined as XML child elements - see table 10.115.

    As far as I could tell from a quick scan, all other "attributes" listed in tables with such a name are actually also XML attributes.
    So I can see how there could an interpretation, that the target of a link event should be an XML attribute and not a child element.
    Am I correct in assuming that the XSD is binding and thus "target" should really not be an attribute of the linkEventDefinition element, but rather a child element?
    If so, then this section should be defined in a less ambiguous way.

  • Reported: BPMN 2.0.2 — Thu, 17 Sep 2020 15:35 GMT
  • Updated: Tue, 22 Sep 2020 19:24 GMT

Please clarify if the usage of a XOR Join is not redundant

  • Key: BPMN21-427
  • Status: open  
  • Source: Blume ( Steffen)
  • Summary:

    Software vendors seem to implement it as a mandatory step to close every XOR Gateway with a XOR Join.
    It seems that even the majority of users which can be found in the internet, assume or state that the XOR Join element has to used everytime a XOR Gateway is opened.
    Just a few sources state that the usage of the XOR Join gateway is optional.

    Since i don't see a definitie logical reason, to use the XOR Join gateway at all, i was researching the OMG BPNPs specifications, which seem not to clrarly state how to handle XOR Joins either.
    Therefore i open up this issue. Could you please state:

    1. is there really an imgainable situation, in which the XOR Join makes sense? Is this element really needed?
    2. What is your recommendation in usage?

    Thank you very much for any clarification

  • Reported: BPMN 2.0.2 — Mon, 2 Mar 2020 10:56 GMT
  • Updated: Mon, 2 Mar 2020 15:58 GMT

Is there a definite reason to exist for a XOR join gateway?

  • Key: BPMN21-426
  • Status: open  
  • Source: Blume ( Steffen)
  • Summary:

    Please excuse that i ask this question by opening this bug report. SInce i wasn't able to find a definite answer to the given question in the specification, it may more be a bug in terms of an missing clarification, which seem to lead to the situation, that certain software providers handle the use of a XOR Join Gateway in a way, that seem to be redundant, from a strictly logical perspective, by stating the use of a XOR Gateway without the following mandatory use of a XOR Join Gateway as an error.

    There seem to be two different understandings of the handling of the XOR Join gateway. The Majority seems to state, that using this in general would be the best practise, whereas I think, that the logical aspect should be paramount. (Form follows function). That is why I was starting to research for an official explanation.

    So, could the OMG point out:
    A: Which possible Situation could logically justify the existance of this element?
    B: What a desired best practice in the use of this element would be?

    Thank you very much for your help
    sincerly yours

  • Reported: BPMN 2.0.2 — Wed, 26 Feb 2020 09:28 GMT
  • Updated: Wed, 26 Feb 2020 17:34 GMT

Event list seems to be not complete

  • Key: BPMN2-317
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    On p. 241 is written:

    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.

    and on p. 174:

    The Start Event trigger (EventDefinition) MUST be from the following types: Message, Error,
    Escalation, Compensation, Conditional, Signal, and Multiple (see page 259 for more details).

    It seems that Timer and Parallel are missing the list on p. 174.

  • Reported: BPMN 2.0.2 — Thu, 16 Jan 2020 17:50 GMT
  • Updated: Fri, 17 Jan 2020 20:32 GMT

Misprint in call activity view

  • Key: BPMN2-316
  • Status: open  
  • Source: Kyiv ( Yevhen Mazhuha)
  • Summary:

    “Call activity” in the table looks like “None” (not market in bold).

  • Reported: BPMN 2.0.2 — Wed, 15 Jan 2020 14:12 GMT
  • Updated: Fri, 17 Jan 2020 20:32 GMT

Different explanation and example.

  • Key: BPMN2-315
  • Status: open  
  • Source: Kyiv ( Yevhen Mazhuha)
  • Summary:

    Example about figure 6.52 shows not about driver`s story

  • Reported: BPMN 2.0.2 — Wed, 15 Jan 2020 14:11 GMT
  • Updated: Fri, 17 Jan 2020 20:31 GMT

Example uses invalid DI attributes and wrong namespaces

  • Key: BPMN21-425
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    The example in section 15.3.1 Document Structure on page 475 (PDF 505) uses invalid Diagram Interchange (DI) attributes and fails XML schema validation. The example seems to use an older DI version than the one published with BPMN 2.0. This is also visible in the different namespace URLs used.

    diagram1.bpmn:7: element BPMNDiagram: Schemas validity error : Element '{http://www.omg.org/spec/BPMN/20100524/DI}BPMNDiagram', attribute 'scale': The attribute 'scale' is not allowed.
    diagram1.bpmn:7: element BPMNDiagram: Schemas validity error : Element '{http://www.omg.org/spec/BPMN/20100524/DI}BPMNDiagram', attribute 'unit': The attribute 'unit' is not allowed.diagram1.bpmn:8: element BPMNPlane: Schemas validity error : Element '{http://www.omg.org/spec/BPMN/20100524/DI}BPMNPlane', attribute 'element': The attribute 'element' is not allowed.
    diagram1.bpmn fails to validate
    

    A fixed version that passes XML schema validation is available at:
    https://github.com/bpmn-miwg/bpmn-miwg-demos/tree/master/2020-06-omg-technical-meeting-boston/discussion/BPMN%202.0.2%20Section%2015.3.1%20Document%20Structure%20Example

  • Reported: BPMN 2.0.2 — Thu, 7 Nov 2019 08:46 GMT
  • Updated: Mon, 11 Nov 2019 19:57 GMT

"Flow Object" should be "Flow Node"

  • Key: BPMN21-421
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says in the (non normative) glossary:

    Flow Object - A graphical object that can be connected to or from a Sequence Flow. In a Process, Flow Objects are Events, Activities, and Gateways. In a Choreography, Flow Objects are Events, Choreography Activities, and Gateways.

    In the metamodel, the common superclass of Event, Activity, Choreography Activity, and Gateway is FlowNode. Does that mean, Flow Object and Flow Node are synonyms? Or is Flow Object the graphical object and Flow Node the model element? Both words are used throughout the specification, e.g.

    Table 7.3 displays the BPMN Flow Objects and shows how these objects can connect to one another through Sequence Flows.

    Of the types of Flow Node, only Activities, Gateways, and Events can be the target [of a Sequence Flow].

    Does it serve any purpose to have different names for the two? I find it confusing.

    Suggestion
    Replace all occurrences of "Flow Object" with "Flow Node".

  • Reported: BPMN 2.0.2 — Wed, 14 Nov 2018 17:22 GMT
  • Updated: Tue, 27 Nov 2018 20:46 GMT

Typo:

  • Key: BPMN21-420
  • Status: open  
  • Source: DAQRI ( Paul Chen)
  • Summary:

    Section 12.1.1 includes the text "miss-interpretations"

    The correct spelling is "misinterpretations"

  • Reported: BPMN 2.0.2 — Thu, 1 Nov 2018 23:40 GMT
  • Updated: Fri, 2 Nov 2018 14:01 GMT

Typo in example

  • Key: BPMN21-419
  • Status: open  
  • Source: DAQRI ( Paul Chen)
  • Summary:

    Section 6.1.1 includes this bullet point on conventions:

    • The cardinality of any content part is specified using the following operators:
    • <none> — exactly once

    I don't know whether this should be:
    • <1> — exactly once
    or
    • <one> — exactly once

    I could not find any examples of this syntax in the standard.

  • Reported: BPMN 2.0.2 — Thu, 1 Nov 2018 23:36 GMT
  • Updated: Fri, 2 Nov 2018 14:01 GMT

Diagram 8.1 looks amateurish

  • Key: BPMN21-418
  • Status: open  
  • Source: DAQRI ( Paul Chen)
  • Summary:

    Diagram 8.1 looks amateurish: the non-horizontal text labels are not aligned linearly, nor are the letters spaced evenly. The circular rings look like they were cut out of construction paper. This diagram doesn't have the quality one would expect to see in a formal international standard published by the OMG.

  • Reported: BPMN 2.0.2 — Thu, 1 Nov 2018 23:20 GMT
  • Updated: Fri, 2 Nov 2018 14:00 GMT

Wrong sub-section reference numbers

  • Key: BPMN21-417
  • Status: open  
  • Source: DAQRI ( Paul Chen)
  • Summary:

    The third paragraph of section 2.1 says:

    "The implementation claiming conformance to the Process Modeling Conformance type SHALL comply with all of the requirements set forth in sub clause 2.1. The implementation claiming conformance to the Process Execution Conformance type SHALL comply with all of the requirements set forth in sub clause 2.2. The implementation claiming conformance to the BPEL Process Execution Semantics Conformance type SHALL comply with all of the 2 Business Process Model and Notation (BPMN), v2.0.2 requirements set forth in sub clause 2.3. The implementation claiming conformance to the Choreography Conformance type SHALL comply with all of the requirements set forth in sub clause 2.4. The implementation is said to have BPMN Complete Conformance if it complies with all of the requirements stated in sub clauses 2.1, 2.2, 2.3, and 2.4."

    Each of the sub-section numbers referenced is off by 1. The correct paragraph text should be:

    "The implementation claiming conformance to the Process Modeling Conformance type SHALL comply with all of the requirements set forth in sub clause 2.2. The implementation claiming conformance to the Process Execution Conformance type SHALL comply with all of the requirements set forth in sub clause 2.3. The implementation claiming conformance to the BPEL Process Execution Semantics Conformance type SHALL comply with all of the 2 Business Process Model and Notation (BPMN), v2.0.2 requirements set forth in sub clause 2.4. The implementation claiming conformance to the Choreography Conformance type SHALL comply with all of the requirements set forth in sub clause 2.5. The implementation is said to have BPMN Complete Conformance if it complies with all of the requirements stated in sub clauses 2.2, 2.3, 2.4, and 2.5."

  • Reported: BPMN 2.0.2 — Thu, 1 Nov 2018 21:16 GMT
  • Updated: Fri, 2 Nov 2018 14:00 GMT

Inconsistent BPMNShape Attributes in tables

  • Key: BPMN21-415
  • Status: open  
  • Source: PragmaDev ( Mihal Brumbulli)
  • Summary:

    Collapsed activities have "None or isExpanded is false" as BPMNShape Attributes, while their corresponding Expanded form have "None or isExpanded is true".
    "None" should not appear in both forms as it creates confusion.
    This issue is present in the tables of Ad Hoc Sub-Process, Transaction, and Call Activity, but not in those of Sub-Process, Event Sub-Process, and Call Choreography Activity.
    Hence, the former group of tables should be corrected based on the later.

  • Reported: BPMN 2.0.2 — Thu, 19 Jul 2018 09:59 GMT
  • Updated: Tue, 7 Aug 2018 14:09 GMT

Inconsistent semantics of multiple none start events

  • Key: BPMN21-413
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says:

    10.5.2 Start Event All Flow Objects that do not have an incoming Sequence Flow SHALL be instantiated when the Process is instantiated.

    There are some exceptions to this rule, but they don't touch the following discussion. Since Events are Flow Objects, this applies also to Start Events: When the process with multiple Start Events is instantiated, all Start Events of this instance are instantiated (i.e. they get a token).

    Further down it says however:

    There MAY be multiple Start Events for a given Process level. Each Start Event is an independent Event. That is, a Process instance SHALL be generated when the Start Event is triggered.

    That means on instantiating a process, each Start Event gets instantiated, which in turn instantiates a new process. I don't think this was intended.

    In the same section the semantics for calling global processes is defined differently (without mentioning it as an exception to the above rule):

    If the Process is used as a global Process and there are multiple None Start Events, then when flow is transferred from the parent Process to the global Process, only one of the global Process’s Start Events will be triggered.

    So called global Processes are treated differently from Subprocesses (I know, somewhere else it is stated, that a Subprocess can only have a unique Start Event - a rule that is contradicted in the immediately following sentence). I think this is confusing.

    Suggestion
    Change the above sentence

    All Flow Objects that could have but do not have an incoming Sequence Flow SHALL be instantiated when the Process is instantiated.

    This way, multiple Start Events are always alternative. This would be in line with many other sections of the specification:

    13.2 Process Instantiation and Termination A Process is instantiated when one of its Start Events occurs. Each occurrence of a Start Event creates a new Process Instance [...] Note that two Start Events are alternative [...]

    and

    13.3.4 Sub-Process/Call Activity If the Sub-Process does not have incoming Sequence Flows but Start Events that are target of Sequence Flows from outside the Sub-Process, the Sub-Process is instantiated when one of these Start Events is reached by a token. Multiple such Start Events are alternative. [...]

  • Reported: BPMN 2.0.2 — Thu, 28 Jun 2018 18:01 GMT
  • Updated: Tue, 7 Aug 2018 14:03 GMT

Attribute called

  • Key: BPMN21-412
  • Status: open  
  • Source: Salient Process ( Neil Kolban)
  • Summary:

    The text today reads:

    An ItemAwareElement MAY be underspecified, meaning that the structure attribute of its ItemDefinition is optional if the modeler does
    not wish to define the structure of the associated data.

    I believe it should be:

    An ItemAwareElement MAY be underspecified, meaning that the structureRef attribute of its ItemDefinition is optional if the modeler does
    not wish to define the structure of the associated data.

    The ItemDefininition doesn't have an attribute called "structure".

  • Reported: BPMN 2.0.2 — Thu, 7 Jun 2018 19:15 GMT
  • Updated: Tue, 12 Jun 2018 15:11 GMT

Relationship relates CMOF::Element, not Artifact

  • Key: BPMN21-411
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says about External Relationships:

    These extensions’ intention is to extend the semantics of a given BPMN Artifact.

    The following text then refers consistently to BPMN Artifacts.

    The metamodel however specifies that a Relationship links all kinds of CMOF::Elements, not just BPMN::Artifacts.

    My guess is, that "BPMN Artifacts" was meant to read "BPMN elements", e.g.

    typed relationships that enable BPMN and non-BPMN Artifacts to be related

    should probably read

    typed relationships that enable BPMN and non-BPMN Artifacts elements to be related

  • Reported: BPMN 2.0.2 — Thu, 31 May 2018 12:33 GMT
  • Updated: Tue, 12 Jun 2018 15:11 GMT

Unclear how to add new Artifact Types

  • Key: BPMN21-410
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says about Extension:

    It provides a set of extension elements, which allows BPMN adopters to attach additional attributes and elements to standard and existing BPMN elements.

    In other words, extension can only add something to existing elements, but not create new element types.
    However about Artifacts it says:

    A modeler or modeling tool MAY extend a BPMN diagram and add new types of Artifacts to a Diagram.

    Given the extension mechanism, it is unclear, how new types of Artifacts can be added. And since the Metaclass Artifact is abstract, it is not possible to use the generic Artifact and extend it to create something resembling a new type. A modeler would always need to specify the concrete subclass, such as Group or TextAnnotation and thus inherit attributes and semantics he probably doesn't need.
    So either the sentence is wrong, or there is another extension mechanism, that needs some explanation here.

  • Reported: BPMN 2.0.2 — Thu, 31 May 2018 12:20 GMT
  • Updated: Tue, 12 Jun 2018 15:11 GMT

Derivation of categorizedFlowElements is only given by visual nesting

  • Key: BPMN21-409
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says:

    categorizedFlowElements:FlowElement [0..*] - The FlowElements attribute identifies all of the elements (e.g., Events, Activities, Gateways, and Artifacts) that are within the boundaries of the Group.

    This attribute is derived and the elements are found by looking at the diagram and determining, which elements are within the boundaries of the dashed box representing the Group. As far as I know, this is the only place in the specification, where the location of an element in the diagram is relevant for the semantics. I think there should be a more formal way.
    Further down the specification says:

    Groups are one way in which Categories of objects can be visually displayed on the diagram.

    If the only way to define a group is to show it in the diagram (as the first sentence implies), this sentence is wrong.

  • Reported: BPMN 2.0.2 — Wed, 30 May 2018 13:24 GMT
  • Updated: Tue, 12 Jun 2018 15:10 GMT

Some of the descriptions in the bpmnElement column of the table are incorrect

  • Key: BPMN21-408
  • Status: open  
  • Source: PragmaDev ( Mihal Brumbulli)
  • Summary:

    The description in the bpmnElement column of the table for the Sequence Flow, Conditional Sequence Flow, and Default Sequence Flow elements is incorrect. default neither is an attribute of the listed elements, nor it is of type boolean. It belongs to the element referenced by the sourceRef attribute, and can either reference an element or be undefined (it cannot be false).

  • Reported: BPMN 2.0.2 — Tue, 20 Mar 2018 16:36 GMT
  • Updated: Fri, 6 Apr 2018 19:33 GMT

Add start and intermediate events of type "User"

  • Key: BPMN21-406
  • Status: open  
  • Source: Atom Software Pty Ltd ( Paul Hopkins)
  • Summary:

    Introduce start and intermediate events of type “User”. Events of type User can be used to identify user initiated actions for example pressing a door-bell or selecting a menu item on a computer. At the moment the BPMN specification only allows these events to be modelled as conditional events or alternatively through the BPMN extension mechanism. Unfortunately the majority of vendors do not support the extension mechanism, they only support the main specification. Adding this to the main specification would greatly improve the BPMN's applicability and usability.

  • Reported: BPMN 2.0.2 — Mon, 19 Mar 2018 11:57 GMT
  • Updated: Fri, 6 Apr 2018 19:29 GMT

Outgoing sequence flows from event gateways should allow conditional expressions

  • Key: BPMN21-405
  • Status: open  
  • Source: Atom Software Pty Ltd ( Paul Hopkins)
  • Summary:

    Allow event-based gateways to have outgoing conditional flows. Section 10.6.6 of the BPMN specification v2.0.2 states that “The outgoing sequence flows of the event gateway must not have a conditional expression”. I suggest that this clause be changed because an initiating event-based gateway is an excellent way to model, for example, a menu, where not all items on a menu are available all the time (as they might depend upon user roles or the application’s state). With outgoing conditional flows from the event-based gateway this situation can be modelled easily. Of course modelling a menu is only one such scenario, and I appreciate that the conditions to be applied to the conditional flows could instead be applied to the events following the event-based gateway, but the use of conditional flows is simply a cleaner implementation.

  • Reported: BPMN 2.0.2 — Mon, 19 Mar 2018 11:52 GMT
  • Updated: Fri, 6 Apr 2018 19:28 GMT

Probable contradiction: Implicit compensation and Throwing Compensation Events

  • Key: BPMN21-403
  • Status: open  
  • Source: omninet.de ( Frank Munkert)
  • Summary:

    In table 10.88 "End Event Types", the table row with header "Compensation" contains this statement:
    "To be compensated, an Activity MUST have a boundary Compensation Event or contain a Compensation Event Sub-Process."
    The same applies to Table 10.89 "Intermediate Event Types in Normal Flow" on page 251.

    On page 234, however, there is this statement: "The compensation handler is either user defined or implicit."

    The two statements, taken together, would mean that an implicit compensation handler cannot be called by a Throwing Compensation Event.

    This probably is not intended.

    Either the concept of implicit compensation should be removed alltogether (which is not my preference), or alternatively the sentence
    "To be compensated, an Activity MUST have a boundary Compensation Event or contain a Compensation Event Sub-Process."
    should be changed like this:
    "To be compensated, an Activity MUST have a boundary Compensation Event or contain a Compensation Event Sub-Process, or the Activity must be a Sub-Process or a Call Activity calling a Process."
    because sub-processes and called processes always are implicitly compensable (unless the compensable attribute is set to false).

  • Reported: BPMN 2.0.2 — Thu, 5 Oct 2017 09:46 GMT
  • Updated: Wed, 18 Oct 2017 06:09 GMT

Define "Cancellation" more precisely

  • Key: BPMN21-404
  • Status: open  
  • Source: omninet.de ( Frank Munkert)
  • Summary:

    Chapter "10.5.1 Concepts" contains the following statement on page 234:
    "Cancellation will terminate all running Activities and compensate all successfully completed Activities in the Sub-
    Process it is applied to. If the Sub-Process is a Transaction, the Transaction is rolled back."

    The standard, however, is a little bit vague about what actually triggers cancellation.
    Here are just a few examples of scenarios in whose descriptions the standard applies the term "cancel":

    • Throwing Cancel Event
    • 'cancelRemainingInstances' attribute of Ad-Hoc Sub-Processes
    • 'completionCondition' attribute of Multi-Instance Activities
    • 'condition' attribute of ComplexBehaviorDefinitions
    • 'isInterrupting' attribute of Start Events in Event Sub-Processes
    • 'cancelActivity' attribute of boundary events

    Do all these scenarios trigger a cancellation in the sense of the above mentioned statement?
    This should be explained more precisely in the standard.

    Furthermore, on page 301, there is this statement:
    "Cancellation in turn can result in compensation of already successfully completed
    portions of an active Activity, in case of a Sub-Process."

    Why does the statement use "can result" instead of e.g. "always results"?
    The standard should describe precisely under which circumstances cancellation results in compensation, and the circumstances under which cancellation does not result in compensation.

  • Reported: BPMN 2.0.2 — Thu, 5 Oct 2017 12:47 GMT
  • Updated: Wed, 18 Oct 2017 05:55 GMT

Intermediate Compensation Events can have outgoing Sequence Flows

  • Key: BPMN21-402
  • Status: open  
  • Source: omninet.de ( Frank Munkert)
  • Summary:

    In chapter 10.5.4 "Intermediate Event", on page 258, there is the following sentence:
    "An exception to this: an Intermediate Event with a Compensation trigger MUST NOT have an outgoing Sequence Flow (it MAY have an outgoing Association)."

    This statement seems to be wrong. For example, figure 10.32 on page 176 shows several throwing Intermediate Events with outgoing sequence flows.

  • Reported: BPMN 2.0.2 — Wed, 4 Oct 2017 08:45 GMT
  • Updated: Wed, 4 Oct 2017 20:13 GMT

Execution semantics of Activity with conditional outgoing Sequence Flows

  • Key: BPMN12-35
  • Status: open  
  • Source: Munkert Software Consulting ( Frank Munkert)
  • Summary:

    In chapter "13.3.2 Activity", on page 429, there is the following bullet point:

    "* After all completion dependencies have been fulfilled, the state of the Activity changes to Completed. The outgoing
    Sequence Flows becomes active and a number of tokens, indicated by the attribute CompletionQuantity, is
    placed on it. If there is more than one outbound Sequence Flows for an Activity, it behaves like an implicit
    Parallel Gateway."

    The last cited sentence does not take into consideration that the outgoing sequence flows might have conditions. Therefore, the statement "behaves like an implicit Parallel Gateway" is not entirely correct.

    Suggestion for a revised version of the last sentence:
    If there is more than one outbound Sequence Flows for an Activity, and if all outbound sequence flows are unconditional, the Activity behaves like an implicit Parallel Gateway. If there conditional outgoing sequence flows, the behavior is as described in "13.3.1 Sequence Flow Considerations".

  • Reported: BPMN 2.0.2 — Mon, 29 May 2017 08:38 GMT
  • Updated: Tue, 27 Jun 2017 15:16 GMT

p.172 Reference pointing to wrong figure, p.174/175 Event marker missing in figure

  • Key: BPMN21-400
  • Status: open  
  • Source: Combitech Systems AB ( Hakan Davidsson)
  • Summary:

    p.172: "... Sub-Process marker, seen in Figure 10.24 ..." Should be Figure 10.25

    p.174/175: p.174, "... its Start Event will be used as a marker in the upper left corner of the shape (see Figure 10.30)." There is no marker in Figure 10.30 (I suppose it should be the Message Event from Figure 10.31).

  • Reported: BPMN 2.0.2 — Thu, 3 Nov 2016 11:35 GMT
  • Updated: Fri, 4 Nov 2016 20:55 GMT

Inconsistent default value of dataStore/@isUnlimited

  • Key: BPMN21-399
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    Table 10.55 (Data Store attributes) defines the default value of isUnlimited as false whereas the XML Schema says:

    <xsd:attribute name="isUnlimited" type="xsd:boolean" default="true"/>
    

    Proposal:
    In Table 10.55 (Data Store attributes) on page 208 (PDF 238) replace:
    > isUnlimited: boolean = false
    with:
    > isUnlimited: boolean = false

  • Reported: BPMN 2.0.2 — Tue, 13 Sep 2016 17:55 GMT
  • Updated: Tue, 27 Sep 2016 20:16 GMT

Clarification needed regarding converging exclusive gateway and slash marker

  • Key: BPMN21-398
  • Status: open  
  • Source: Munkert Software Consulting ( Frank Munkert)
  • Summary:

    On page 290, in section "10.6.2 Exclusive Gateway", there is the following text:
    "A converging Exclusive Gateway is used to merge alternative paths. Each incoming Sequence Flow token is routed
    to the outgoing Sequence Flow without synchronization."

    On page 435, in section "13.4.2 Exclusive Gateway (Exclusive Decision (data-based) and Exclusive Merge)", there is the following text in the table:
    "Exception Issues - The exclusive gateway throws an exception in case all conditions evaluate to false and a default flow has not been specified."

    I.e. according to the table, in order not to throw an exception, a converging exclusive gateway would need to have a default flow marker on its single outgoing sequence flow. This seems to be a contradiction to the description in section 10.6.2. Therefore, this should be clarified in both sections, e.g. using a sentence like this: "The single outgoing sequence flow of a merging exclusive gateway is implicitly assumed to be the default sequence flow. A slash marker MAY be shown in diagrams for such sequence flows."

    Without such a clarification, BPMN process diagrams where an outgoing sequence flow of a converging exclusive gateway has no slash marker would be wrong. Since those diagrams are very common (e.g. OMG's "BPMN 2.0 by Example", v1.0, page 36), it should be explicitly mentioned that omitting the slash marker is allowed.

  • Reported: BPMN 2.0.2 — Tue, 16 Aug 2016 06:35 GMT
  • Updated: Fri, 19 Aug 2016 13:25 GMT

Task Description -- Internal Conflict

  • Key: BPMN21-397
  • Status: open  
  • Source: US Army ( Michael Gilsdorf)
  • Summary:

    Sect 10.3.3 states, "A Task is used when the work in the Process cannot be broken down to a finer level of detail."

    However, the task definition in the glossary states, "A Task is used when the work in the Process is not broken down to a finer level of Process Model detail."

    The phrase, "cannot be broken down" is much different than the phrase, " is not broken down". The latter suggests that an activity could be broken down further, but was not.

    The glossary definition is correct since a task can often be broken down into tiny actions (e.g., Click the left mouse button), but a person modeling the process may choose not to model to that low a level. Thus, a task is the lowest level shown on a diagram, but may not necessarily be the lowest possible level.

    Recommend that the sentence in Sect 10.3.3 be changed to be consistent with the one in the glossary. As an option, you also may wish to make that statement, "Any conflicts between the glossary and other parts of the specification, the glossary takes precedence."

  • Reported: BPMN 2.0.2 — Sat, 6 Aug 2016 18:49 GMT
  • Updated: Wed, 10 Aug 2016 14:06 GMT

data storage element is missing in overview

  • Key: BPMN21-394
  • Status: open  
  • Source: Diartis AG ( Daniel Canonica)
  • Summary:

    In the overview 'Basic BPMN Modeling Elements', table 7.1, the data storage element (hard disk Symbol) is missing. (Refer to section 10.4.1, Figure 10.54).

  • Reported: BPMN 2.0.2 — Wed, 13 Apr 2016 13:13 GMT
  • Updated: Wed, 13 Apr 2016 15:36 GMT

Confusion over dataOutput attributes

  • Key: BPMN21-393
  • Status: open  
  • Source: Cognitect ( David Chelimsky)
  • Summary:

    Table 10.60, which describes the attributes of DataOutput objects, describes "outputSetwithOptional" with "Each OutputSet that uses this DataOutput can determine if the Activity can complete executing without producing this DataInput. This attribute lists those OutputSets." I believe that "DataInput" should be replaced with "DataOutput".

    Similarly, the same table describes the "outputSetWithWhileExecuting" attribute with "Each OutputSet that uses this DataInput can determine if the Activity can produce this DataOutput while executing. This attribute lists those OutputSets." Same correction applies.

  • Reported: BPMN 2.0.2 — Mon, 29 Feb 2016 21:57 GMT
  • Updated: Wed, 2 Mar 2016 07:12 GMT

Wrong table reference number

  • Key: BPMN21-389
  • Legacy Issue Number: 19766
  • Status: open  
  • Source: ERP Bulgaria Ltd. ( Ivan Argentinski)
  • Summary:

    There are actually 2 errors (wrong Table numbers) in the last 2 sentences on the page:

    "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."

    The correct Table numbers should be:

    • ItemAwareElement (Table 10.51)
    • DataObject (Table 10.52)
  • Reported: BPMN 2.0.2 — Sun, 31 May 2015 04:00 GMT
  • Updated: Mon, 22 Jun 2015 06:12 GMT

Missing event marker in Figure 10.30

  • Key: BPMN21-369
  • Legacy Issue Number: 19473
  • Status: open  
  • Source: omninet.de ( Frank Munkert)
  • Summary:

    The specification says: "If the Event Sub-Process is collapsed, then its Start Event will be used as a marker in the upper left
    corner of the shape (see Figure 10.30)."

    But the referenced figure does not show any marker event. Therefore, either the text or the figure is wrong.

  • Reported: BPMN 2.0.2 — Mon, 16 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 10.3.4 Human Performer is not peorperly defined for implementation interpretation

  • Key: BPMN21-366
  • Legacy Issue Number: 19461
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    It is not specifically stated in the spec whether "HumaPerformer" is an abstract class.
    It seems to be, but then the meta model (fig 10.23) depicts only one specialization namely "PotentialOwner" leaving in question the need for this abstraction.
    Furthermore "PotentialOwner" only

  • Reported: BPMN 2.0.2 — Wed, 11 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Second occurance of sequential Multi-Instances should be parallel

  • Key: BPMN21-374
  • Legacy Issue Number: 19709
  • Status: open  
  • Source: Anonymous
  • Summary:

    In Table 7.2 the text for Multiple Instances says the three vertical lines mean sequential MI. I believe it nust be parallel, three horizontal lines mean sequential.

  • Reported: BPMN 2.0.2 — Wed, 14 Jan 2015 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use of per mille symbol unclear (‰)

  • Key: BPMN21-373
  • Legacy Issue Number: 19708
  • Status: open  
  • Source: Anonymous
  • Summary:

    In table 7.3 the per mille (‰) sign is used in the third column. I suspect the arrow was meant.

  • Reported: BPMN 2.0.2 — Wed, 14 Jan 2015 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT