How can we rerun a record if it got failed when we are using unique reference?

Hi All

We are reading some emails from outlook and required records are fed into the queue. The keyword in the email subject is the unique reference of the queue items.

Our plan is if any transaction gets failed we need to Unread the particular email in the outlook so that in the next bot run the email will enter into the queue freshly as a new entry. But as we have already used the email subject keyword as the unique reference the it won’t enter into the queue.

So how can we design the bot so that the failed email should again run in the next run ?

you can go to queue settings and make the Unique References option set to OFF

no no . we have to set it to Yes.

alternatively you can also postpon the item and not fail, if you postpone it, it will be process in the next run

Postpone Transaction Item (


Along with the mail subject use a timestamp as well in REFERENCE property like this inside the loop


This will make that reference as unique for each object added to queue

Cheers @kkpatel

What happens when you have the Queue set to auto retry? Does the unique setting prevent it from re-adding the queue item?

in case of retry bot doesn’t add the item into the queue again. Queue loading part is inside the First Run sequence.

I’m not talking about the bot adding it again. I’m talking about these settings when creating the Queue:


This means that when you set a transaction to Failed (Application), Orchestrator marks it retried and automatically adds it to the Queue again. But the two items are linked for tracking purposes since it’s a retry, so maybe this overrides the Unique setting.

Got it!

You can go for Postpone Item logic. That will solve the issue

Postpone is unnecessary. Use the built-in retry features of the Queue. It works even with Unique set to on. To trigger the queue retry, set the transaction to Failed (Application).


We know the Auto Retry would make the failed items go back in the queue.

“I believe” the requirement is to process the next day and not in the same day or same execution.

@kkpatel can give us more idea about his requirements.

The original post says:

So how can we design the bot so that the failed email should again run in the next run ?

Doesn’t say next day. Says next run. Maybe the next run is the next day, but that doesn’t matter with respect to the queue item.

Yes I read that clearly :slight_smile:

Thinking logically there would not be any requirement to process such transaction again instantly, hence I mentioned, “I believe” it should not be processed in the same run.

@kkpatel can only let us know the details on when the failed items need to be processed

Let us see what is the requirement first. Auto Retry and Postpone are both fine.

Hi @kkpatel,

My inputs as below:

  1. If you have implemented this using re-framework, item will be automatically retried for the number of times you have specified in queue configuration in orchestrator folder.
  2. But if your requirement is even if it failed after no of retries, in the next bot run, you should be able to add that item then there are few below options you can pick from:
    a. Prefix your reference with datetime, so no matter if the keyword in subject is same, you can always add that again and again.
    b. Not so recommended way but its there - delete the failed items and then you will be able to add same item again in the queue for processing.

Hope this helps.


You are right. After all the retries are finished and still its in failed state then in the next run bot should unread the email and re load the same email to process.

The option which @Palaniyappan said is the best option to implement i feel.


This is a good point, the queue retry would process again during the current run.

1 Like

To make it even more better we can use this activity Mark mail as read at last if the transaction got failed and in order to retry with that mail details

While adding reference alone include timestamp along with mail subject so that each time the reference will be unique and it will work fine as expected, as simple as it is

Cheers @kkpatel

I am probably a little late to the party. I had been having worries about this as well, if you really had to pick between Unique reference and auto retry. What @postwick has said is correct. I tried out creating a REF project using unique reference and inside Process throwing a System Exception. The workflows inside SetTransactionStatus that add a failed transaction again to the queue work. Other cases like if you try adding items to queue with Add Queue item that is already there it throws an exception about duplicated entries.

1 Like