I'm modeling shipment creation sequence diagram.
User creates shipment request -> system checks container/voyage candidates (reference to generate candidates diagram).
(1)If candidates exist -> user selects or declines.
(2)If no candidates -> shipment marked as pending, freight forwarder notified.
Now 3 possible paths:
(a) User cancels the shipment.
(b) User waits, and eventually freight forwarder may create a voyage that can transport user shipment, when creating the voyage (voyage creating sequence diagram) it checks all pending shipments to assign possible candidates (also reference the generate candidates diagram), if a possible candidate found for our shipment notifies user and back to (1).
(c) Freight forwarder does nothing or creates a voyage schedule that does not align with our shipment's route, and the shipment request remains pending until timeout.
The key challenge is how to represent the possibility of (b), the voyage being created later, which is not a direct result of the initial interaction, it may or may not happen at some point in the future.
Modeling Asynchronous Interactions in shipment Lifecycle
Just looking at the title of your question one can imagine the solution is to use an asynchronous message, but it's body indicates this is not the way to do because things are more complicated.
b isn't done by the system itself managing lately an asynchronous message associated to a pending request created in 2 , but because a human manager looks at the voyages and may be creates a new one etc
The key challenge is how to represent the possibility of (b), the voyage being created later, which is not a direct result of the initial interaction, it may or may not happen at some point in the future.
b, and not only it, is just decoupled with 1 and 2. 1 and 2 are two alternatives in the same tree of message, whose root is the shipment request done by a user, a b and c aren't in it, that's all. Of course for 1 and 2 use a combined fragment alt.
As I understand a is done lately by the user, so it is also separated with the other management, I mean without a common root message. But it is surely part of a more complex interaction, like the a user access to his shipment requests and can cancel some of them etc.
One can imagine to use a combined fragment par to separate 1+2 with a and b and c, but that just complicates the things without adding a real plus value, it is better to use separated sequence diagrams. Notice also some parts must be done in critical section, but to show that with the corresponding combined fragment is useless for me.
The separation between b and c seems a little artificial, at least you cannot place a b and c at the same level because there are two different actors initiating the managements. Very probably in the same way a pending request is done in 2, an other one is done in a and will be taken into account lately by the manager among what you name b/c.
... back to (1).
Not possible, because 1 and b are decoupled