Actually both, it depends on the design.
You have two available activity to initialize queue items
Add queue item & Add transaction Item
The first one will add to your Orchestrator queue an item with the Status “new” and will have to be picked from the queue later using “Get Transaction Item” Activity, generally from another process. This Load work approach mainly allow your workload to be processed between several robots
Add transaction Item will directly start a queue item and put its Status as “in process”. It is quite handy and allows you to bypass the load phase if you do not intend to split the workload between several robots or see a need to process your transactions
Note that for both approaches, you have the possibility to attach data and output to each item which is quite helpful in term of understanding the case processed (For reporting or testing purpose).
At the end, you should set a status to your queue item (Failed or Completed) or even do more advanced thing such as postponing it using appropriate activities.
Queues also offer a very good retry management which help to keep the workflows lean and since the latest version allow you to avoid unwanted processing duplication with their unique reference options
In the case we were talking about I would see:
Start Initial job -> Start Transaction Item -> Set Status-> Add queue Item to second queue If Success -> Job2 will Get Transaction Item -> Set Status -> Load 3rd queue - > Work (and so on…)
This is just a proposed design and other might also be good or even better
If one of the jobs (or its transactions, if you abstract rather the workload) is/are failed, simply the second process would run blank without incidence.
Queues and transaction may look unnecessary and tedious for some people at the first look, but I can guarantee you that with a bit of practice and learning, you can clearly see that both from development, support or business side, this makes everything simpler at the end.
Info here is surely incomplete! Recommend anyone: