When should we use Enforce Unique References vs Idempotency to prevent duplicate transactions?

Help Orchestrator
1

Hi everyone,

I’m trying to understand the practical difference between Enforce Unique References in Orchestrator Queues and idempotency in automation design.

From my understanding:

  • Enforce Unique References prevents duplicate queue items from being added to the queue.
  • Idempotency prevents duplicate business operations if the bot retries or reruns a transaction.

My questions are:

  1. In a real production project, should we rely only on Enforce Unique References, only on idempotency, or implement both?
  2. Can someone provide a real-world example where idempotency is required even though Enforce Unique References is already enabled?
  3. What are the best practices for implementing idempotency in UiPath projects (especially in REFramework)?

For example, if a bot creates an invoice in SAP but crashes before calling Set Transaction Status, the queue item may be retried. In that case, would the bot first check whether the invoice already exists in SAP before creating it again? Is this what idempotency is intended for?

I’d appreciate any real-world examples or best practices.

Thank you!

2

@Abhinay_Reddy1

Your understanding is correct, and in production-grade automations the answer is usually: implement both.

Enforce Unique References and idempotency solve different problems at different layers.

  • Enforce Unique References is an Orchestrator queue-level protection.

    • It prevents the same Reference value from being added twice to the same queue.
    • It only controls queue insertion.
    • It does not guarantee the business action itself happened only once.

  • Idempotency is a business-process protection.

    • It ensures the target system ends in the correct state even if the automation retries, crashes, resumes, or runs multiple times.
    • It protects against duplicate business outcomes such as duplicate invoices, payments, orders, emails, tickets, etc.

So in enterprise projects, unique references are useful for queue hygiene, while idempotency protects business integrity.

3

Hi @Abhinay_Reddy1

In orchestrator we use the unique references to block duplicate items being added. As you have said. The flaw with this is that when the ingress either does not set a reference or the contents in the queue items are a duplicate from another item with a different reference this check ultimately fails.

My approach for your example would be to have a check built into your process before you process the invoice for a possible duplication in the system and then throw a business rule exception stating the duplication possibility. This also protects the data quality on the system since the item will then not be posted again thus ensuring idempotency.

I would still put some retry logic around the status updates to orchestrator as this should not be failing. Are you on premise or cloud hosted for your Orchestration? If this is network related the retry will also assist.

Real world example of this:

I am capturing invoices into Sage X3 for a client. My input is from an external system doing the data extraction, but the bot captures into Sage X3 as they have very limited API functionality. While the transaction is processing upfront there is a pop up that reflects possible duplication linked to the Supplier code and Supplier invoice number. If this does appear I throw a business exception for the end users to investigate. :robot:

Hope this helps.

4

Hey @Abhinay_Reddy1

enforce unique references is mostly for ur business data. like if you dont want two queue items with the same invoice number ever, u just turn this on in the queue settings.

idempotency is more about network safety. like if you are using api calls to add items and the connection drops, your code might retry the same request. the idempotency key makes sure the server knows its the exact same request so it doesnt add it twice by mistake.

so basically use unique ref for your business rules and idempotency for safe api retries.

hope this helps :slight_smile: