Set Transaction Progress



Hi @qateam

I see that you have implemented Set Transaction Progress in the new version! I haven’t looked at it too closely yet but assuming this is the progress update that we asked for a while back??

If so, you guys rock!! Well you rock anyway :smiley:


Progress in job queue is empty after completion
Queue Improvements (Delete, Query)

Hi Team.

Me again. It seems that the Transaction Progress is not persistent once the status of the queue item has been changed. E.g. if set back to New or postponed any update to the Transaction progress is lost.

Could you check this please and amend for next version?



There is a lot to improve when it comes to queues. I need to manage workload and I cannot use half of these activities… I am a bit disappointed with UiPath, because I really enjoy programming with the tool and doing RPA.


The queues are great. What problems are you having?


For example

  1. you cannot set a transaction to “In Progress” unless you use the activity “Get Transaction Item” (which only supports random choice of queue item - the first in the queue)
  2. the only activity that allows filtering the type of item u extract cannot set a transaction to “In Progress” (“Get Queue Items”)
  3. transaction progress is only relevant for the RPA administrator/auditor. The robot cannot make any use of this data
  4. Removing an item from a queue on orchestrator does not delete it, it just changes the status to “Deleted”. If you want to remove it, you have to delete the queue an create a new one with the same settings

Im sure I would find other issues if I kept on going. I dont want to be disrespectful to the hard work of UiPath’s employees as im sure I would not do better, but this is almost useless the way it is right now (the queues package in UiPath studio)… :confused:

If I am wrong, please enlighten me, as it would be very useful for my current project. I really want this technology to be successful, because I see potential in it and I hope to benefit from this opportunity. Otherwise, one year of my life has been wasted.

  1. You can do things to ensure that the item you place in the queue gets picked first, e.g. use priority. Not often that you need to do this but there is a way.
  2. What do you mean by filtering? There are ways in which can use the APIs to do things that you perhaps can’t using the existing activities.
  3. The transaction progress was something I requested a while back but when it was implemented it wasn’t persisted to the database, this will be updated in a future release
  4. Why would you ever want to delete an item? This removes auditability. If you do want to do this then you can run SQL statements against the database - however, you risk breaking the dependencies between underlying tables.



I assume you are referring to this API:

By filtering I mean this:

The problem is this activity does not change the status of items from “New” to “In Progress” when it extracts them from the queue.

Transaction progress is not the same as transaction status. I was talking about transaction status.

Because if the item fails and I want to retry the item by running the automation again, the automation inserts the item back into the queue. But this time it fails because of the unique reference constraint of the queue. So the queue has to be changed to non-unique.
Now imagine the robot retries and inserts the same item twice (due to a bug). Now that item is processed one time too many.


Hello @productEnt,

Getting this back to the original topic a second. It seems that the persistence of Transaction Progress is now fixed in the latest release BUT (I have been told) if you postpone the queue item it wipes the Progress. Can you consider whether actually it would be better to retain this information? For example, I’ve done steps 1 and 2 but need to wait X days before I can continue. However, I need to restart from Step 3.




If you have retries on the queue then Orchestrator will automatically retry the case and reset that item to new. You shouldn’t be adding the same item to the queue.

Sorry, if I’m not understanding perhaps if you could provide a specific example of what you are trying to do that may help.

Ultimately the queue mechanism has worked for us in many real projects and is flexible enough to achieve the results we need.

Also, there is now an activity for get All Queue items which allows you to run queries - this may be useful to you.


Hi there @richarddenton,
You are absolutely correct.
The feature is soooo close to being perfect, but has one minor oversight.

Setting the progress and failing the item (granted queue retries are applicable), creates a new case, with the same information/history, which can be pulled and its progress retrieved!

This means we can more accurately perform retries, directing the case to the relevant segments of the process.

BUT, as you’ve noted, postponing the item does not achieve this :frowning:

If you set the progress and then postpone, the item is reset to ‘New’ and the progress is lost.

Outside of this, the features now works fantastically and will potentially alter how we design/develop :smiley:


How to retrieve exception reason or exception details from Orchestrator QueueItem

Hi, I am trying to use this “Set transaction progress” feature, but my problem is I am unable to read it back to the process. I just did a little test where I use Get transaction item and then Set transaction progress, followed by a message box to display the progress of the transaction item (I have tried with transItem.Progress and transItem.Progress.ToString). My problem is that even though I can see in Orchestrator that the progress has been altered, if I click View Details for the transaction item, then the message box does not display the progress (just an empty string). I also tried giving it a few seconds waiting time after setting the progress in order to let it refresh, didn’t work.

Has anyone got a clue what is going on?