Trying to use the same reference once it is already used will throw an exception. So you would need to check that the reference already exists or set the ContinueOnError to True (if it has that property)
I agree, and there are times when this is applicable, when adding a date or datetime will allow more freedom for an end user that utilizes the process. For example, if they need to process many invoices, there might be times when they need to do the same invoice again, which then you would need to decide if you want to restrict the same invoice to a day or job run time.
On the other hand, there are many other times in which you would want to not include the date for items that are consistent and duplicates would not occur unless by mistake. In this scenario, you may consider a workflow component to reset the Failed, so even if the item went through its retries, and you want to attempt it again, you don’t need to do any manual steps to reset the item. In addition to that, you would want a due date, which in the version I’m using (2018), is not accessible from the transactionItem variable and it seems the Queue doesn’t automatically close the item by due date - so, a Get Queue Items activity is needed (to match with reference) plus a sequence to change the status to Failed if due date is passed. While this point is not that important, there is still the potential where you could have an item that sits there and never completes, so due date would disable it after some time. […incoming learning curve]
In both cases, you will want to only add queue items that don’t exist already by the reference. To do this, you can do something like this (after a Get Queue Items):
I believe I used the Try Catch, so it would skip the item counter. I’m using the counter so I can Log the number of items which were added out of the total number of items.