Queues retry is configured as 3.
Transaction Performs
Step1: Create Customer
Step2: Create Account
Step3: Assign Product
Step4: Send Welcome Email
Customer creation (step1) succeeds, but Account creation (step2) failed.
Orchestrator retries the transaction from the beginning.
what is the wrong with the design? how to optimize the code.
If it will fail on the 2nd step, then next time it should run from the 2nd step in UiPath reframework not starting.
Hi @kumar5626
The issue is that all 4 steps are treated as one queue transaction, so REFramework retries the transaction from the beginning.
To optimize:
Example:
CustomerCreated = True → Skip Step 1 → Start from Step 2
This makes the process restartable and prevents duplicate records.
it just an example for 4 steps, let say we have 100+ steps then this logic will not work, so in that case how we will handle this problem in multibot.
can we solve with queue activities like set transaction progress?
Yes, for 100+ steps, you should not create separate flags for every step.
If you’re using REFramework + Orchestrator Queues, you can use Set Transaction Progress to store the current progress of the transaction.
For example:
Step 1 → Step 2 → Step 3 → Step 4
If Step 2 fails, set the transaction progress to something like “Step 2”. On the retry, read the transaction progress and continue from Step 2 instead of starting from Step 1.
For a Multi-Bot setup, this is a much better approach because the progress is stored with the queue item and can be used by the next bot/retry.
Hi @kumar5626,
Welcome to the community.
A better approach is to make each step restart-safe. For example, before creating the Customer, check whether the Customer already exists. If it exists, skip Step 1 and move to Account creation. Similarly, before creating the Account or assigning the Product, check whether that operation has already been completed.
You can also maintain the last successfully completed step for each transaction. For example, after Step 1 succeeds, store Step1; after Step 2 succeeds, store Step2, etc. When the transaction is retried, read this value and resume from the next pending step. Expore the Activities - Set Transaction Progress activity.
Another option is to handle duplicate scenarios using the application’s built-in response. For example, if Step 1 returns “Customer already exists”, treat it as a successful completion of that step and continue with Step 2.
So, rather than trying to make REFramework resume execution from the exact activity where it failed, the better design is to make the transaction idempotent and checkpoint-based. This ensures that retries don’t unnecessarily repeat actions that have already been completed.
Thanks!
I think best approach will be using State machine. Store the last successful state in a asset or some persistent logic and in your Process.xaml use state machine to execute the next step than the previously reported successful step.
I need to make changes in my existing RE-Framework. so, anyone can help me to find the solution.
Hi @kumar5626,
Add a checkpoint field by adding a Key-Value pair to the queue item’s SpecificContent to store LastCompletedStep. Update it immediately after each step succeeds instead of updating it at the end of the process.
Then branch on the checkpoint inside Process.xaml. Use a Switch/Flow Decision keyed on LastCompletedStep:
Similarly, you can add any number of steps in this approach. On retry, Orchestrator re-invokes “Process.xaml” for the same item, but your logic now resumes instead of restarting.
Hope this helps.
Cheers!
Hi @kumar5626,
First, identify which solution best suits your requirement from the suggested options, and then start implementing it in your REFramework.
If you face any issues during implementation, you can post the specific issue on the UiPath Forum, and the community can help you find a solution.
If the query has been resolved, could you please mark the answer as the solution?
Thanks!
