Prev Next


A Decision Node used in Activity Diagrams as depicted using Sparx Systems Enterprise Architect.


A Decision is an element of an Activity diagram or Interaction Overview diagram that indicates a point of conditional progression: if a condition is True, then processing continues one way; if not, then another.

The element can also be used as a Merge node in that multiple alternative flows can be merged (but not synchronized) to form one flow. These examples show both of these methods of using the Decision element.

Used as a decision:

Example of a Decision Element used to model a decision in Sparx Systems Enterprise Architect.

See the OMG Unified Modeling Language specification, (v2.5.1, figure 12.77, p. 363.)

Used as a merge:

An example of a Decision element as a merge, in Sparx Systems Enterprise Architect

See the OMG Unified Modeling Language specification, (v2.5.1, figure 12.106, p. 388.)

You can choose a Behavior element as the Decision Input property of the Decision (UML: decisionInput) in the Properties window. To show the chosen Decision Input property on a diagram, attach a Note to the Decision, then right-click on the Note Link and choose the 'Link this Note to an Element feature' option. Then select 'Decision Input' as the linked feature.

You can also choose an Object Flow as the Decision Input Flow of the Decision (UML: decisionInputFlow). Select the incoming Object Flow and select the 'Decision Input Flow' option in the Properties window.


  • Moving a diagram generally does not affect the location of elements in Packages; if you move a diagram out of one Package into another, all the elements in the diagram remain in the original Package

    However, Decision elements are used only within one diagram, have no meaning outside that diagram, and are never re-used in any other diagram; therefore, if you move a diagram containing these elements, they are moved to the new parent Package with the diagram

Toolbox icon

Decision element

Learn more

OMG UML Specification:

The OMG Unified Modeling Language specification, (v2.5.1, p.390 (Decision Node)) states:

A DecisionNode is a ControlNode that chooses between outgoing flows. A DecisionNode shall have at least one and at most two incoming ActivityEdges, and at least one outgoing ActivityEdge. If it has two incoming edges, then one shall be identified as the decisionInputFlow, the other being called the primary incoming edge. If the DecisionNode has only one incoming edge, then it is the primary incoming edge. If the primary incoming edge of a DecisionNode is a ControlFlow, then all outgoing edges shall be ControlFlows and, if the primary incoming edge is an ObjectFlow, then all outgoing edges shall be ObjectFlows.

A DecisionNode accepts tokens on its primary incoming edge and offers them to all its outgoing edges. However, each token offered on the primary incoming edge shall traverse at most one outgoing edge. Tokens are not duplicated.

If any of the outgoing edges of a DecisionNode have guards, then these are evaluated for each incoming token. The order in which guards are evaluated is not defined and may be evaluated concurrently. If the primary incoming edge of a DecisionNode is an ObjectFlow, and the DecisionNode does not have a decisionInput or decisionInputFlow, then the value contained in an incoming object token may be used in the evaluation of the guards on outgoing ObjectFlows.