DEV Community: Pravinraj Vincent

UiPath Pitfall #4: A Variable With the Same Name as Your Argument

Pravinraj Vincent — Fri, 30 Oct 2026 00:56:01 +0000

You assign a value to your Out argument, a Message Box right after says it's filled, and a few activities later (or back in the parent workflow) it's Nothing. No error and no runtime warning. It's just empty.

This came up again on the UiPath Forum in Out param Nothing when leaving Do, and it's one of those bugs that makes you doubt Studio itself.

The cause

Most of the time, a variable and an argument share a name.

You've got out_Result in the Arguments panel, and somewhere along the way a variable called out_Result also got created, often scoped to a Sequence or a Do block. Inside that scope, your Assign writes to the variable. Outside it, you're reading the argument, which never got touched.

The Managing Arguments docs spell it out: if a variable and an argument have the same name, the variable is always the one used at runtime. The same goes for two variables in different scopes of one file. The inner scope wins.

How it sneaks in

For me it's usually Ctrl + K in the To field of an Assign. That shortcut creates a new variable, not an argument. So if you type the argument's name and hit Ctrl + K, you've just made a duplicate scoped to wherever you were.

(Ctrl + M is the one that creates an In argument.)

The fix

Find the duplicate. Select the container (click the Do, Sequence or Try block, not just the root) and check the Variables panel for the argument's name. Delete the variable, keep the argument, then re-pick the argument in the Assign.
Let Workflow Analyzer catch it. Run Analyze File or Analyze Project from the Design ribbon. There are rules for exactly this:
- ST-NMG-006 Variable Overrides Argument
- ST-NMG-005 Variable Overrides Variable

If you're on a team, set ST-NMG-006 to Error in the Workflow Analyzer settings. Then it shows up as an error in the Errors panel, which is a lot harder to scroll past.

Use direction prefixes on arguments only. in_, out_, io_ for arguments, never for variables. A variable called out_Something then looks wrong the moment you see it.
Assign the Out argument once. If the value gets built up across several scopes, work on a local variable and assign it to the Out argument once, at the end of the workflow:

' inside the scopes, work on a local variable
resultBuilder = resultBuilder & currentRow("Name").ToString

' last activity in the workflow
out_Result = resultBuilder

Docs

Managing arguments: https://docs.uipath.com/studio/standalone/latest/user-guide/managing-arguments
Managing variables: https://docs.uipath.com/studio/standalone/latest/user-guide/managing-variables
ST-NMG-006 Variable Overrides Argument: https://docs.uipath.com/studio/standalone/latest/user-guide/st-nmg-006
ST-NMG-005 Variable Overrides Variable: https://docs.uipath.com/studio/standalone/latest/user-guide/st-nmg-005
About Workflow Analyzer: https://docs.uipath.com/studio/standalone/latest/user-guide/about-workflow-analyzer
Keyboard shortcuts: https://docs.uipath.com/studio/standalone/latest/user-guide/keyboard-shortcuts

Do you run Workflow Analyzer before every publish, or only when something breaks? Tell me in the original forum thread, that's where the discussion is: https://forum.uipath.com/t/uipath-pitfall-of-the-week-4-a-variable-with-the-same-name-as-your-argument/5786751

Originally posted on the UiPath Forum: https://forum.uipath.com/t/uipath-pitfall-of-the-week-4-a-variable-with-the-same-name-as-your-argument/5786751

Prefer to watch it? Here is the video version: UiPath Studio: Out Argument Is Nothing After Do + Agent LLM HTTP 403.

I post short UiPath fix videos from real forum questions on my YouTube channel, RPA Simplified.

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

Pravinraj Vincent — Fri, 30 Oct 2026 00:55:15 +0000

Your failed queue item never got retried. Or the opposite: the robot hit the same broken item three times in a row. Almost every time, it comes down to which exception type the item failed with.

This question shows up on the UiPath Forum every few weeks in one form or another, so it got its own Pitfall of the Week.

The mistake

Treating Business and Application exceptions as two labels for the same thing, "failed". Orchestrator treats them very differently.

Application exception + Auto Retry turned on for the queue: Orchestrator retries the item, up to the queue's max number of retries.
Business exception: Orchestrator doesn't retry it by default.

That's straight from the Set Transaction Status docs. With ErrorType set to Application, the transaction is retried according to the settings in Orchestrator. With Business, it isn't.

It bites in two directions

A technical problem thrown as a BusinessRuleException. Say a page timeout or a frozen app ends up in the wrong catch. The item goes straight to Failed and never gets a second chance, even though a retry would probably have worked.
A data problem thrown as a plain System.Exception. Missing invoice number, invalid customer ID. The item gets retried, fails the exact same way, and burns runtime. If the failing step is a login with bad credentials, repeated retries can also get the account locked.

In REFramework, what you throw is the decision

REFramework makes the split for you. In SetTransactionStatus.xaml, anything thrown as BusinessRuleException is marked Business, and everything else is marked Application. So the exception type you throw in Process.xaml decides whether the item gets another shot.

A data check in Process.xaml can be as simple as this (VB):

If String.IsNullOrWhiteSpace(in_TransactionItem.SpecificContent("InvoiceNumber").ToString) Then
    Throw New BusinessRuleException("Invoice number is missing")
End If

In Studio you'd normally do this with an If activity and a Throw activity, but the idea is the same.

What I do now

Ask one question before throwing: would running this exact item again, unchanged, have a real chance of working? Yes means Application. No (bad or missing data, a business rule the item fails) means BusinessRuleException.
Validate input data early in Process.xaml and throw BusinessRuleException with a clear message. That way the reason shows up in the transaction details instead of a stack trace.
Handle a shared login failure in the Init state and stop the job, instead of failing every queue item one by one.
Let one layer own retries. The note on MaxRetryNumber in the REFramework Config.xlsx says it must be 0 when you're working with Orchestrator queues. So leave it at 0 and set retries on the queue itself (Edit queue, Auto Retry section).
Retry a single flaky step in place. If one step just needs another try right away, wrap only that step in a Retry Scope (Number Of Retries, Retry Interval) instead of failing the whole item.

Docs

Business exception vs Application exception: https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/business-exception-vs-application-exception
Set Transaction Status: https://docs.uipath.com/activities/other/latest/workflow/set-transaction-status
Managing queues in Orchestrator (Auto Retry): https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/managing-queues-in-orchestrator
Retry Scope: https://docs.uipath.com/activities/other/latest/workflow/retry-scope

Where do you draw the line on the gray areas, like a CAPTCHA, an expired password, or a target system down for maintenance? Join the discussion in the original forum thread: https://forum.uipath.com/t/uipath-pitfall-of-the-week-3-expecting-orchestrator-to-retry-a-business-exception/5785256

Originally posted on the UiPath Forum: https://forum.uipath.com/t/uipath-pitfall-of-the-week-3-expecting-orchestrator-to-retry-a-business-exception/5785256

I post short UiPath fix videos from real forum questions on my YouTube channel, RPA Simplified.

UiPath Pitfall #2: Keeping Your Studio Project in a OneDrive Sync Folder

Pravinraj Vincent — Fri, 30 Oct 2026 00:53:46 +0000

If you're getting vague compile errors like a bare Error code 1, or a project runs on one PC and won't open cleanly on another, check where the project folder lives. If it's inside OneDrive or any always-sync cloud folder, that's very likely your problem.

The mistake

Putting the live Studio project folder inside OneDrive (or Dropbox, or any folder that syncs all the time) so you can "share" it between machines. It feels convenient. It isn't.

Why it bites

Studio writes a lot of files while you work: project.json, generated files, and a local cache in the hidden .local folder. A sync client can lock those files, leave some of them online-only, or still be downloading subfolders when Studio tries to compile.

On the forum that usually shows up as a bare Error code 1, or a project that works on PC1 and won't open on PC2 until someone copies it out of OneDrive. Network and shared drives cause the same kind of pain. Copy the project to a real local disk and it suddenly works.

The fix

1. Keep the working project on a local path.

Studio's default location is:

%USERPROFILE%\Documents\UiPath

But watch out: if Windows has redirected Documents into OneDrive, that default is a synced folder too. In that case put your projects somewhere that isn't synced, for example:

C:\UiPathProjects\

2. Share and version with Git, not by syncing the live folder.

In Studio, go to the Team tab and use GIT Init to add the project to a local Git repository, commit, then push to a remote. TFS and SVN are also supported if that's what your team uses. Studio leaves the .local folder out of source control by default, so your machine cache stays off the repo.

3. Need a cloud copy just for backup?

Zip or copy the project after you close Studio. Just don't develop inside the synced folder.

4. Don't confuse this with Sync to Cloud.

Studio's Sync to Cloud option syncs your project with Studio Web in Automation Cloud. It has nothing to do with OneDrive.

Quick check

Open File Explorer on your project path. If you see OneDrive sync icons on project.json or your workflow files, move the project to a local folder before your next publish.

Docs

About automation projects (default location, .local, Sync to Cloud): https://docs.uipath.com/studio/standalone/latest/user-guide/about-automation-projects
Adding a project to Git: https://docs.uipath.com/studio/standalone/latest/user-guide/adding-a-project-to-git
About version control: https://docs.uipath.com/studio/standalone/latest/user-guide/about-version-control

Had a sync folder bite you? Tell me about it in the original forum thread, that's where the discussion is: https://forum.uipath.com/t/uipath-pitfall-of-the-week-2-keeping-your-studio-project-in-a-onedrive-sync-folder/5783803

Originally posted on the UiPath Forum: https://forum.uipath.com/t/uipath-pitfall-of-the-week-2-keeping-your-studio-project-in-a-onedrive-sync-folder/5783803

I post short UiPath fix videos from real forum questions on my YouTube channel, RPA Simplified.

UiPath Pitfall #1: Relying on idx in Your Selectors

Pravinraj Vincent — Fri, 30 Oct 2026 00:53:37 +0000

If your selector works on some runs and fails on others, open it and look for an idx attribute. Nine times out of ten, that's the problem.

I see this one on the UiPath Forum constantly, so it was the first thing I wrote up in my Pitfall of the Week series.

Why idx breaks

When you indicate an element and Studio can't tell it apart from similar elements, it adds something like idx='3' to the selector. That works on your screen today. But idx is just the element's position in the UI hierarchy, nothing more.

Add a column to a table, get a popup, or have the page load a little differently, and position 3 is now a different element. Or nothing at all. The robot either clicks the wrong thing or times out, and it looks random because it depends on what the screen looked like on that run.

UiPath's own Workflow Analyzer rule for this, UI-REL-001 (Large Idx in Selectors), says the same thing: the order idx relies on can change when the elements you're automating change, so it should be avoided.

The fix

Open the selector in UI Explorer and replace idx with something that actually describes the element. Good candidates:

aaname
id
automationid
innertext

So instead of this:

<webctrl tag='BUTTON' idx='3' />

you'd aim for something like this:

<webctrl tag='BUTTON' aaname='Submit invoice' />

If the stable value changes a bit between runs, use a wildcard. * replaces zero or more characters:

<webctrl tag='SPAN' aaname='Invoice *' />

In Modern activities, add an anchor, meaning a nearby label that never moves, so the target is found relative to something stable. Then keep Fuzzy selector or Image as a fallback targeting method in case the strict selector misses.

A quick check before you publish

Search your project for idx=. Every hit is a possible failure in production.

You can also let Workflow Analyzer do it for you. UI-REL-001 lists every selector with an idx value above the threshold you set, one by one, so you can work through them before they bite.

Docs

UI-REL-001 Large Idx in Selectors: https://docs.uipath.com/activities/other/latest/ui-automation/ui-rel-001
Selectors with wildcards: https://docs.uipath.com/activities/other/latest/ui-automation/selectors-with-wildcards
UI Explorer: https://docs.uipath.com/activities/other/latest/ui-automation/ui-explorer
Advanced descriptor configuration (strict, fuzzy and image targeting): https://docs.uipath.com/activities/other/latest/ui-automation/advanced-descriptor-configuration

Got a selector horror story? Share it in the original forum thread, that's where the discussion lives: https://forum.uipath.com/t/uipath-pitfall-of-the-week-1-relying-on-idx-in-your-selectors/5783645

Originally posted on the UiPath Forum: https://forum.uipath.com/t/uipath-pitfall-of-the-week-1-relying-on-idx-in-your-selectors/5783645

I post short UiPath fix videos from real forum questions on my YouTube channel, RPA Simplified.