How can I represent a "wait until customer representative is available" in the UML activity diagram below? A solution in UML 1 or UML 2 are both acceptable.

Proposal 1

wait state model

The simple line back to the second condition "looks" wrong.

Proposal 2

I also came up with this "cleaner" solution.

enter image description here

(I know that the final point is missing.)

  • 1
    Your two proposals don't seem to represent the same thing to me. It looks like the first goes through multiple iterations of wait, while the second only does a single wait
    – Peter M
    Jun 26, 2017 at 12:51
  • 1
    I think uml-diagrams.org/activity-diagrams-reference.html shows how to model send event signal. or accept action event.
    – oopexpert
    Jun 26, 2017 at 23:30
  • Find this activity diagram tutorial to be very useful in figuring out questions like these. There are many examples and templates drawn on various scenarios to identify questions like these.
    – Shalin
    Oct 10, 2018 at 6:58

5 Answers 5


IMHO, there is actually no need to include any conditional or "loop" for the "wait" state at all:


Any activity needs a certain time until it is completed. If a customer representative is available immediately, the time for the wait activity is zero, if not, the activity will just take some minutes or maybe hours. But the power of "zero" is it can be often handled just like any other number, without the need for artificial distinctions.

Of course, if you want to model the "Wait" activity explicitly, because in your system something essentially different will happen during a "real wait", go with your solution 2.

  • When I looked the question I was like "hu ? did I miss something, why just not put the text ?", made me doubt for a second.
    – Walfrat
    Jun 26, 2017 at 14:32
  • what if customer representative is never available?
    – Christophe
    Feb 5, 2021 at 16:17
  • @Christophe: this is not part of the OP's original model, either ;-)
    – Doc Brown
    Feb 5, 2021 at 16:41
  • @DocBrown true !
    – Christophe
    Feb 5, 2021 at 16:49

Are your diagrams ok ?

The guard on a decision node shall be placed on the tail of the line and not on the nodes (see UML 2.5 section 15.2.4). So [free customer representative available] on the top of the diamond shall be removed and the outgoing [yes] and [no] change to [customer representative available] and [customer representative not available].

After this, both diagrams would be formally ok:

  • Proposal 2 would produce the expected result if and only if it is guaranteed that a customer representative is available when the wait activity is completed. This is not obvious, so better branch to the left, and put the merge diamond upfront the decision diamond, to be sure not to continue until a representative is available.

  • Proposal 1 is completely correct. The control nodes in an activity diagram are either decision nodes with several outgoing flows, or merge nodes with several ingoing flows (see UML 2.5 section 15.3.2), but fortunately, both can be combined into a single diamond on the diagram (see UML 2.5 figure 15.34 in section It's however a little bit less readable than distinct nodes.

  • You already know, but you'd need an end node after the order.

But is it really the best way ?

Your diagrams rely on the human understanding of the activity wait (for representative). But I think we agree that waiting is not really an activity but rather a not activity.

Alternative 1: use an event driven approach with the help of an accept-event-action called Customer representative available that represents what you're waiting for. Merge the flow coming out of it with your normal flow. Attention: don't use the tempting TimeEvent (hour glass symbol): it is meant for events occurring at specific point in time (see UML 2.5 section

Alternative 2: represent what you're really doing: you're finding a customer representative. This is the simpels way to show it.

enter image description here

Alternative 3 (my favorite): represent the true complexity of a multitasking world, with the use of a fork and a join control, and in-between everything that is happening in parallel:

enter image description here

  • 2
    Thank you very much for the elaborate answer. Question regarding alternative 3 and the join control: Wouldn't your model mean that I would have to wait for the music to finish playing until a order could be placed? Jun 26, 2017 at 19:30
  • Well, indeed, you are completely right: the join will wait that music playing is finished, which might not be the most effective way to get the order placed. To solve this you could use an (interrupting edge)[uml-diagrams.org/activity-diagrams.html#activity-edge] with an event action, as in alternative 1. More complex, but at least the customer would at least have the music;-) .
    – Christophe
    Jun 26, 2017 at 20:10

If you use swim-lanes, I think you don't need any wait mechanism. It's implied that the Customer Representative has to be ready to do the task.

Here's a suggestion done with PlantUML/PlantText:

enter image description here

EDIT Here's another suggestion (source) with a more explicit wait semantic that allows for hanging up.

enter image description here


Having a "wait" state, or wait activity, is not implausible, and depending on the domain, not uncommon either. Mark it as such and defined how long the state will be active for (i.e. how long it it goes back to the decision point).

If the decision point doesn't have to be explicitly exposed, you can roll the decision and wait state into a single activity that moves on the availability of an operator.

On a side note; if the OP is a "demo" of the actual flow being assessed in your project, there are other options for models and modeling this behavior that may be worthwhile investigating, such as;

  • FSM, a state with an event that moves the machine on to the "place order" state
  • If there are multiple flows that require synchronisation, a join may be a better idea

Sometimes other solutions may just be another model, or a redesign of some sort that removes the wait state. That said, often then solution is just the wait state because that's the behavior of the process flow being modeled (whether that is by design or by analysis).

On the added second option, the "wait until" inherently requires a test to determine if the required condition is satisfied, I'm not sure the second option models that appropriately.

  • How should I model "howl ong the state will be active for" in UML? Jun 26, 2017 at 12:04
  • 1
    @problemofficer. On the added second option, the "wait until" inherently requires a test to determine if the required condition is satisfied, I'm not sure the second option models that appropriately. It looks neater, but I'd feel the model is not right.
    – Niall
    Jun 26, 2017 at 12:06
  • @problemofficer. If you don't really like the form of the arrow from the wait state, you can redraw that, most modeling tools support various layout options. What tool are you using?
    – Niall
    Jun 26, 2017 at 12:07
  • The delay time can be a note, or in the name.
    – Niall
    Jun 26, 2017 at 12:08
  • I am using draw.io. Jun 26, 2017 at 12:09

You should use a ReceiveSignalAction to represent receiving of a signal that a consultant is ready.

Sorry, no modeling tool available at the moment, I'll add the diagram when I sit to my computer.

Not the answer you're looking for? Browse other questions tagged or ask your own question.