As promised, here is my first cut at a single list of the rules of BPMN, both the official rules from the spec (prefixed BPMN) and my “method and style” rules (prefixed Style). All are implemented in my Method and Style Validation tool. Note: for now, this list assumes the model includes no event subprocesses.
- BPMN 0101. All flow objects other than start events, boundary events, and compensating activities must have an incoming sequence flow, if the process level includes any start or end events.
- BPMN 0102. All flow objects other than end events and compensating activities must have an outgoing sequence flow, if the process level includes any start or end events.
- BPMN 0105. A start event cannot have an incoming sequence flow.
- BPMN 0106. A start event cannot have an outgoing message flow.
- BPMN 0107. A start event with incoming message flow must have a Message trigger.
- BPMN 0109. A start event cannot have an Error trigger.
- BPMN 0111. A start event in a subprocess must have a None trigger.
- BPMN 0112. A boundary event must have an outgoing sequence flow.
- BPMN 01122. A boundary event trigger must be either Message, Timer, Signal, Error, Escalation, Conditional, Cancel, or Compensation.
- BPMN 01123. A boundary event cannot have incoming sequence flow.
- BPMN 01124. An Error boundary event on a subprocess requires a matching Error throw event.
- BPMN 01126. An Error boundary event cannot be non-interrupting.
- BPMN 01127. An Escalation boundary event on a subprocess requires a matching Escalation throw event.
- BPMN 0113. An intermediate event with incoming message flow must be catching type with Message trigger.
- BPMN 0114. An intermediate event with outgoing message flow must be throwing type with Message trigger.
- BPMN 01151. A throwing intermediate event result must be either Message, Signal, Escalation, Link, or Compensation.
- BPMN 01161. A catching intermediate event trigger must be either Message, Signal, Timer, Link, or Conditional.
- BPMN 0119. A throwing Link event cannot have outgoing sequence flow.
- BPMN 0120. A catching Link event cannot have incoming sequence flow.
- BPMN 0124. An end event cannot have outgoing sequence flow.
- BPMN 0125. An end event cannot have incoming message flow.
- BPMN 0126. An end event with outgoing message flow must have Message result.
- BPMN 0132. A gateway cannot have incoming message flow.
- BPMN 0133. A gateway cannot have outgoing message flow.
- BPMN 0134. A splitting gateway must have more than one gate.
- BPMN 0138. An event gateway must have either a catching intermediate event or Receive task on each gate.
- BPMN 0202. A sequence flow cannot cross a pool or subprocess boundary.
- BPMN 0203. A conditional sequence flow cannot be used if there is only one sequence flow out of the element.
- BPMN 0204. Sequence flow out of a parallel gateway cannot be conditional.
- BPMN 0301. A message flow cannot connect nodes in the same pool.
- BPMN 0302. A message flow can only come from a Messege end or intermediate event; Send, User, or Service task; Subprocess; or black box pool.
- BPMN 0303. A message flow can only go to a Message start or intermediate event; Receive, User, or Service task; Subprocess; or black box pool.
- Style 0050. A child-level diagram should not be enclosed in an expanded subprocess shape.
- Style 0051. The label of a child-level page should match the name of the subprocess.
- Style 0103. Activities should be labeled.
- Style 0104. Two activities in the same process should not have the same name. (Use global activity to reuse a single activity in a process.)
- Style 01041. A Send task should have an outgoing message flow.
- Style 01042. A Receive task should have an incoming message flow.
- Style 0110. A Message start event should have an incoming message flow.
- Style 01101. A Message start event should be labeled “Receive [message name]”.
- Style 01102. A Timer start event should be labeled to indicate the process schedule.
- Style 01103. A Signal start event should be labeled to indicate the Signal name.
- Style 01104. A Conditional start event should be labeled to indicate the condition.
- Style 01105. A start event in a top-level process should be labeled. If a top-level process contains more than one start event, all should be labeled to identify the alternative start conditions.
- Style 01106. Only one start event should be used in a subprocess.
- Style 01121. A boundary event should be labeled.
- Style 01125. An Error boundary event on a subprocess should be labeled to match the throwing Error event.
- Style 01128. An Escalation boundary event on a subprocess should be labeled to match the throwing Escalation event.
- Style 0115. A throwing intermediate event should be labeled.
- Style 01161. A catching intermediate event should be labeled.
- Style 0122. A catching Message event should have incoming message flow.
- Style 0123. A throwing Message event should have outgoing message flow.
- Style 0127. Two end events in a process level should not have the same name. If they mean the same end state, combine them; otherwise give them different names.
- Style 0129. An end event should be labeled with the name of the end state.
- Style 0135. An exclusive, inclusive, or event gateway should have at most one unlabeled gate.
- Style 0136. An exclusive, inclusive, or event gateway with an unlabeled gate should be labeled.
- Style 0137. If a subprocess is followed by a yes/no gateway, at least one end event of the subprocess should be labeled to match the gateway label.
- Style 0304. A message flow should be labeled with the name of the message.
- Style 0305. A message flow from a collapsed subprocess should be replicated in the child-level diagram.
- Style 0306. A message flow to a collapsed subprocess should be replicated in the child level diagram.
- Style 0307. An incoming message flow in child level diagram should be replicated in the parent level.
- Style 0308. An outgoing message flow in child level diagram should be replicated in the parent level.
[…] This post was mentioned on Twitter by alextoussaint, Ken Ng. Ken Ng said: For all you BPM practitioners… The Rules of BPMN http://j.mp/dCg4Ao […]
Bruce,
Thanks a lot for sharing these valuable rules. It’s a great check list for manually validating a BPD, and hope you make it public!
Hi Bruce,
Thanks a million for this “quick hit” list. Nice one.
[…] “style” rules, listed in a previous post, are mostly about proper labeling to ensure top-down traceability of the diagram. So you […]
Bruce,
This is great stuff. Thank you – especially for the rules.
[…] labeling BPMN diagrams is to have an automated tool check your model over and report violations of the rules. It doesn’t find every problem, but it finds a lot of them, even in my own […]
Just a quick question. I’m looking into BlueWorksLive, and I noticed that it has capability to save to Powerpoint. However, it would seem that only the Discovery Diagram and Documentation views can be saved to ppt — I don’t see a way to save the swimlane view to ppt. Am I wrong?
I think you need to direct that question to IBM. Sorry.
Hi Brian. I’ve found the best way to view the “swimlane” or business process model diagram is to click “print” and choose “plotter” and then “create pdf”. That will allow you to email or print the entire process model from Blueworks Live.
Bruce, I’ve recently purchased the book “BPMN method and style”. I´d like to know if there have been significant changes in the BPMN 2 spec from the publication date (June 2009) up to now, or which are the main issues that I should consider (because of the publication date). Best regards,
The notation is virtually unchanged. There is a new “instantiating” event gateway used at the start of a process (where it means the same as multiple triggered start events), and a Parallel event that waits for ALL of a set of incoming signals (as opposed to Multiple event that waits for ANY of a set of signals). Neither one will get much use, in my opinion. I don’t remember what it says in the book about it, but you can now have one pool in a diagram; earlier you needed to have 2 or more or it was schema-invalid. The biggest changes are in the XML, things I couldn’t get done in the drafting stage but which did get in the final, notably the process modeling conformance classes (subsets of the BPMN palette, a practical necessity for model interchange) and a real schema for the graphics info. Other than that, pretty much same as the book.
[…] section, and also we had covered a lot of these already in the exercises and the method. He did a blog post with a first cut of the rules and style of BPMN, both the standard BPMN rules and his style guidelines, plus a later post showing an example of […]
Hello, just noticed something in the list of rules which does not make sense to me…
BPMN 01127. An Escalation boundary event on a subprocess requires a matching Escalation throw event.
For escalation events, you need a throw, and a catch…would the last part of the sentence read “A matching escalation catch event”
Let me know if I’m not seeing this correctly,
Ozzy
Not quite. An Escalation event on a subprocess boundary implies a throwing Escalation event (end or intermediate) in the child level expansion. It could possibly be considered a style rule rather than a rule of the spec (although an Escalation boundary event on subprocess with no corresponding throw makes no sense). Since the Escalation code does not appear in the diagram, my rule also says the labels of thrower and catcher should match. The same thing applies to Error throw-catch.
Dear Bruce,
I have a query, In one pool with 2 lanes say A & B, is it possible if, Lane A throws intermediate event with message sign and is received in sequence flow by Lane B showing catch intermediate event with message sign? If not, kindly let me know the reason.
regards,
Mark
No this is definitely not allowed. The source and target of a message may not be elements of the same process. A “message” in BPMN is NOT the same as a “message” in English. Within a process, sequence flows and gateways, not messages, are used to synchronize activities.
Dear Bruce,
Thanks for the reply.Does this mean, an intermediate message event should have activity following?
regards,
Mark
Not necessarily. Only if you need an activity to take some action.
Hi Bruce,
Can you clarify, escalations, new in v2. Is an escalation similar to a signal, in as much as multiple events can “catch” a single “thrown” escalation? Can an escalation span process boundaries? If so when would you use an escalation instead of a signal?
Regards,
Jon.
Escalation is not like Signal. It is the non-interrupting counterpart of Error, i.e. exception thrown by a process activity.
Hi Bruce,
Is it allowed to nest a pool within a pool? Or can we only nest lanes within a pool?
Regards,
Jon.
You may not nest a pool within a pool. A process may contain lanes, and a lane may contain child lanes. This is all in the BPMN metamodel.
–Bruce
I’m trying to model that a specific task occurs / must occur within a 48-hour period. I was trying to do this by using a parallel gateway, where one flow went to the task and another flow went to an intermediate timer event of 48 hours. Is this allowed? (We’re only using a subset of BPMN at this time, so I’m a little limited by which symbols I can use.)
BPMN does not have a way to say something “must occur” or “usually occurs” within some duration. It says what action is taken if something takes longer than the duration. Normally you use boundary event or event subprocess for that, but sounds like you don’t have this, just catching event. I’ll bet you’re using Blueworks Live. Sigh. Anyway, you can hack in some deadline triggered behaviors by enclosing your parallel split in a subprocess. Put a terminate event after the task, and put the timeout-handler activity after the timer event on parallel path, followed either by Terminate end event (modeling a quasi-interrupting timeout, quasi because the interruption occurs after the handler) or a None end event (modeling a non-interrupting timeout).
Can I construct conditional message flow (-similar to conditonal sequence flow) in the BPMN Process diagram.
Requirement:- Sub-process from one pool/participant has to communicate with other pool/participant, when specific condition is met; otherwise it has to go-thru other activity in the same pool.
Because it is not a flow of control, most message flows are implicitly conditional already, e.g. out of User task or black box pool. A message flow out of Send task or throwing message event is unconditional.
Hi Bruce,
Great list!
Regarding Rule BPMN 0107, can the incoming message flow to the start event (message trigger) be FROM an intermediate event, message trigger, throwing type in another Pool)?
I can’t find any documentaion to say that’s not correct, but I’m using EA Sparx and the application will only allow me to do an incoming message flow to a start event (message trigger) from an Activity in another Pool.
Just wondering if there’s part of the standard that I’ve missed, or if EA Sparx is simply not allowing this.
Thanks.
Lisa
@Lisa,
Yes the source of the message can be any throwing message node – activity, end event, intermediate event, or black box pool. Sounds like a tool bug.
–Bruce
Dear Bruce,
Thanks for this great list!
I’m just a bit puzzled with the following two rules: To me it appears to be that Style 0135 will always be overruled by #0136.
Style 0135. An exclusive, inclusive, or event gateway should have at most one unlabeled gate.
Style 0136. An exclusive, inclusive, or event gateway with an unlabeled gate should be labeled.
Or does the verb ‘should’ actually mean being optional, while the verb ‘must’ implies a mandatory ruling? (I noticed that the verb ‘must’ is used for BPMN-rules only, while Style rules uses the verb ‘should’. Is there a particular reason for this?).
Regards,
lars
lars,
This post is 4 years old, so some of the style rules may have changed. Anyway, 0135 deals with labeling of the gates (outgoing sequence flows). Now I would say that XOR and OR gateways should label ALL the gates; event gateway should not label the gates but label the events on each gate. 0136 deals with labeling of the gateway (diamond shape) itself. Now I would say that XOR gateway with gates “yes” and “no” should be labeled. If gates of XOR or OR gateway are all labeled, then no need to label the gateway. Event gateway should not (need not) be labeled. I used “should” for the style rules since they are just conventions not rules of the spec.
Bruce, thank you for the elobarated list. But, i am a beginner in BPMN. I am very much interested in learning BPMN. Could you please provide example diagrams to the listed rules.
Ram, I suggest my book BPMN Method and Style 2nd edition, or the BPMessentials training for that.