Anatoly has a good post on a process anti-pattern, which is a process that shows a "sure" message receive (in other words, doesn't allow for other outcomes - an approval process without a "reject" path for example, or a "time-out" path).
Of course, the simpler version of the process is fine for getting the basics of the process down, but you have to make sure you don't base estimates on the simple representation, when there is more effort to make a more robust implementation work correctly.
I described an alternate (work-around) pattern that works on BPMS tools that support multiple attached events on an activity in the comments of Anatoly's post, but I thought it only fair to supply an actual diagram here (click to enlarge):
I left out the second pool and cross-pool messaging to simplify the diagram a bit for purposes of posting here.? Essentially, rather than use an "event gateway" which looks ahead in the diagram to figure out which event fired and therefore which path is followed, we use attached events to do the same thing - if any of these events fire, it will close the activity and move down the path to the next activity.? Of course, the events could be configured so that they don't close the activity they're attached to (for example, a timing event could warn you of a delay, rather than canceling due to a delay).
It isn't "pure" BPMN diagramming to do this the way I've drawn it - but with pretty much every BPM vendor these days you have to make some compromises to get the job done, and BPMN certainly gives you more than one way to solve any problem you're presented with.? As Anatoly mentioned in his post: most of the BPM vendors consider the event gateway a "luxury" and therefore don't implement it, or don't implement it fully.? Hopefully one of the vendors will take the entire BPMN spec seriously, or one of the open source projects will, and put pressure on the others to step it up.