Wait for Queue Item and Resume - execution suspended and process finishing?

Hi everyone :slight_smile:

I have setup a process (process A) using ‘Add Queue Item and Get Reference’ and ‘Wait for Queue Item and Resume’.
In the background I have a process (B) which sees new items that are added to a queue and sets them as Successful.

When trying to run process A from a robot assistant, the process seems to reach the ‘Wait for Queue Item and Resume’ part, then stops straight away saying ‘Successfully Completed’ without carrying on with the rest of the process (which is a simple textbox popup).


Checking the logs, process A seems to reach ‘execution suspended’ then nothing further:

Process B is definitely picking up the queue items and marking them as Successful (very quickly too), so the problem is with process A. You can see from the timestamps above that this isn’t a timeout issue either as the execution is suspended within a second.
A ‘queueItem’ variable is being passed from ‘Add Queue Item and Get Reference’ to ‘Wait for Queue Item and Resume’ so it knows which item to be looking for. I have also re-created the queue as a fresh empty queue but this doesn’t help.

Any ideas as to how to fix this? Or am I missing something?

can you try run it from orchestrator instead of assistant? @ella.wilton
i remember having the same issue if i run it from assistant / studio

Hi Jack.
I have followed your advice to try run via Orchestrator, and am now running into licensing issues?
I get this issue:

But I’m not trying to run something unattended?


  1. If you run from orchestrator by default the bot runs in unattended mode only…
  2. From assistant may be the suspended job needs to be continued and migh tnot start automatically…
  3. To test can you include a log message after the wait for resume


you require unattended license for this

@Anil_G @jack.chan

So if running the process via Orchestrator is out (because I don’t have an unattended license), I’ve added multiple logging messages:

You can see from the logs below that only the first message is logged before the process ends (is suspended and marked as ‘completed’).

In Orchestrator, the job state is ‘Resumed’:

But according to the robot it is completed and nothing further happens.
I can confirm the queue is definitely returning successful transactions:

Seems logical that it resumes right away because the other automation is quickly completing the queue item.

That’s all the queue item will show. It was marked completed (successful) by the second automation. What else were you expecting?

The Process never moves on to the rest of the process - see the part circled in red here is never reached (and there is more below this log message that is never executed):

So it seems to me like the ‘Wait for Queue Item and Resume’ activity is either:
a) Not picking up the successful queue item and for some reason exiting as ‘Successful’ regardless
or b) Receiving the successful queue item back, and for some reason not continuing on with the process.

You shouldn’t use queueItem as a variable name. It’s a datatype. Try changing that variable to something like queueItemObj and see what happens.

Are you running this in Studio? If so, you have to manually resume it in Studio by clicking the button at the top of the window.

Also, you can use the same variable for the input and output of the Wait for Queue Item activity. Doesn’t hurt anything if you use different variables, but it streamlines things if you do, just makes it simpler on you.

Thanks for your help Paul -
I am running this manually after publishing and deploying to an assistant.
I have updated the variable name and simplified to a single queueItem as per your suggestion. Unfortunately this has made no difference.
Very stumped! Will keep mucking about with it.


  1. As per screenshots shared…it looks like the second process is completing the queue items…
  2. First process is suspended and then it is getting resumed also…but no machine is getting identified…as you can see it is resumed but no machine and user is added…that is because you are running in attended mode…this needs an nattended license as attended bots cannot be triggered from orchestrator

  1. Persistant activities would work only with unattended as of now I believe unless you use show form activities which will payse the execution automatically till the form is open…if using any wait taska then the bot type needs to be unattended


Hope this clears the understanding


1 Like

Hi Anil - thanks for your reply.
Is there any activity you know of that can be used to check tor a returned/successful queue item that doesn’t require an unattended license?


If you have the reference stored and if the reference is unique…then you can use get queue items with filter on reference and check if the item is successful or not