UiPath Pitfall #3: Expecting Orchestrator to Retry a Business Exception

Description and use

In UiPath ReFramework, misclassifying exceptions causes incorrect retry behavior in queues. By distinguishing BusinessRuleException from ApplicationException, retries are controlled and failure reasons become clearer.

Problem

Queue items fail without retry or are retried unnecessarily due to incorrect exception classification in UiPath Orchestrator.

Outcome

By distinguishing BusinessRuleException from other exceptions, queue items are retried only when a technical issue may resolve, preventing wasted runtime and improving failure transparency.

Workflow

• 1. In Process.xaml, validate input data early and throw BusinessRuleException for data issues.
• 2. In SetTransactionStatus.xaml, set ErrorType to Business for BusinessRuleException, Application for others.
• 3. Configure Orchestrator queue with Auto Retry enabled and set MaxRetryNumber to 0 in REFramework config.
• 4. Use Retry Scope for flaky steps that need immediate retry without failing the whole item.
• 5. Handle shared login failures in Init state and stop the job if necessary.

Evidence

Application exception + Auto Retry turned on for the queue: Orchestrator retries the item, up to the queue's max number of retries.

Source

Business exception: Orchestrator doesn't retry it by default.

Source

In REFramework, what you throw is the decision.

Source

Ask one question before throwing: would running this exact item again, unchanged, have a real chance of working? Yes means Application. No means BusinessRuleException.

Source