Hi Vinny,

While all those tasks can be performed only after login there is not implication whatsoever that they can be performed in parallel.  As a matter of fact, given the {OR} constraint only one of those tasks can be performed at a time.  I think the diagram is fine.

- Adrian

Hi Vinny,

When you have the situation of multiple activities that can be performed in no particular order after a given step there are multiple ways of modeling this depending on your need.  However, in all cases you will have some type of split mechanism which controls the flow.

Generally, if only one of the following activities can be performed at a given point in time (as is in your example) I like to use a decision in the Activity Diagram (XOR gateway in BPMN).  However, if more than one following activities can be performed at the same time (regardless of order) then you'll need to use the fork in the Activity Diagram.

BPMN (and other more robust workflow notations) on the other had uses gateways for all these uses but it has more granular types of gateways.  For example:

• XOR (exclusive OR) -> only one path can be taken after the split
• OR (inclusive OR) -> multiple paths can be taken after the split (note that at least one path must be taken)
• AND -> all paths are taken after the split (think of parallel paths)
• Complex -> specific logic in the gateway specify which of the paths to take

In addition, BPMN has precise rules for how the flow continues when all those paths merge again.  BPMN has a nice way of looking at all these by considering a token which travels down the execution path.  For example, when the toke reaches an XOR gateway it goes down only one path whereas when the token reaches an AND gateway it splits into multiple tokens with each path getting one token.  When the paths join using an AND gateway the flow does not continue until all the individual token arrive at the merge at which time they become one token again and the execution continues with the next step.

Hope this helps!

- Adrian