Is best practice to use Unique Reference for a large number of queue items?

Hi everyone,

I have an automation that creates queue items in Orchestrator. They cannot be duplicated, so I’m using the Unique Reference property when adding each queue. It tries to add the item, but if it’s duplicated, it throws an exception.

The thing is, we’ll have more than a thousand queue items a day. So, over time, we’ll have a large number of items in the queue. Will this be a problem?

Because, over time, each queue item will be compared to each item processed in the queue, which is going to be a lot. I’m worried that it will cause a big latency after some time.

To check performance best practices, you can go here: Performance Best Practices

You can skip such exceptions enabling “Continue on error” option. If it’s allowed to skip exception handling in your case.

Another workaround. You can disable unique reference and using some kind of ID which is always unique (using timestamp and other parameters).

1 Like


It should not be an issue I believe…these are the limits for retaining queue items in the orchestrator (this is for cloud, might be little different for on prem (you can let us know if your’s is on prem))…but still it will try to store only unique references separately if enabled the option …so that should take care of the issue…

Attaching some references for your help


1 Like

Hi @Slgus ,

I would suggest you not to enforce the unique reference option in the queue.

This is because if at any point you might have to retry the the queue item by cloning it, the UiPath will not allow you if unique reference option is enabled.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.