If you want your UiPath robots to behave like productive employees rather than drama magnets this guide shows how to fetch work with Get Transaction Item and report results with Set Transaction Status while keeping retry logic and error handling under control. No miracles just solid RPA transaction processing that does what it says on the tin.

Prepare the queue and variables

Create a queue in Orchestrator and pick a clear name so future you does not cry. In your workflow define variables such as currentTransaction and transactionItem. These will hold the item you reserve and any state you need while processing.

• Queue name that explains the work
• transactionItem to receive the reserved item
• currentTransaction to store processing state and results

Fetch and lock a transaction with Get Transaction Item

Drop in the Get Transaction Item activity. Point it at the queue name and assign the output to transactionItem. That activity reserves the work item so another robot does not steal the glory or the failure.

transactionItem = GetTransactionItem(queueName)

The reservation makes sure only the robot that claimed the item will work on it until you mark it finished or failed with Set Transaction Status.

Process the transaction data

Extract fields from transactionItem.SpecificContent and run your business logic in small, testable pieces. Modular processing makes debugging less like archaeology and more like controlled excavation.

• Validate inputs and handle missing fields early
• Map data to DTOs or arguments for downstream calls
• Call external systems or perform calculations
• Set a success flag or result object in currentTransaction

Mark results with Set Transaction Status

Once processing finishes use the Set Transaction Status activity to mark the item as Successful or Failed. Add a clear message so the Orchestrator dashboard does not have to guess what happened. Proper status updates keep metrics honest and reporting useful.

SetTransactionStatus(transactionItem, TransactionStatus.Successful, "Processed OK")

If you detect a business rule failure mark it as a business error and skip retries where appropriate. For system failures mark it as a system error so retry logic can take over.

Handle exceptions and retry logic

Wrap your processing in a Try Catch block. Distinguish business exceptions from system exceptions and act accordingly. Business exceptions often mean the data is bad and retries are pointless. System exceptions often deserve a retry or escalation.

• On business error use Set Transaction Status and record the reason for audit
• On system error decide whether to retry or escalate to human support
• Use Orchestrator queue retry settings to control how many automated attempts occur

Remember that a failed status plus a sensible retry policy prevents infinite loops and angry stakeholders.

Test and monitor in Orchestrator

Run the process in a test environment and watch queue counts logs and retry behavior in Orchestrator. Validate that items move through statuses as expected before you consider the process production ready.

• Check Successful and Failed counts in queues
• Inspect logs for exception details and retry traces
• Adjust retry settings and exception handling until results are predictable

Quick checklist before go live

• Queue has a clear name and useful metadata
• Variables are initialized and scoped correctly
• Get Transaction Item reserves items reliably
• Set Transaction Status is used for success and failure reporting
• Try Catch separates business and system errors
• Orchestrator retry settings match your fault tolerance plan

Follow these steps and your UiPath queue processing will be less chaotic and more dependable. If something still fails you at least get a readable failure and can blame the logs instead of your instincts.