I have a scenario where the same UiPath automation needs to run across different environments.
In lower environments such as DEV/UAT, when the application is launched, a Login screen appears and the bot needs to enter the credentials.
In the higher environment, the application uses SSO, so when the application is launched, it directly opens the Home page without showing the Login screen.
For example:
DEV/UAT:
Launch Application
↓
Login Screen
↓
Enter Credentials
↓
Home Page
↓
Business Process
PROD/SSO:
Launch Application
↓
Home Page
↓
Business Process
My initial thought was to attach to the main browser/application instance without depending on a strict window title, and then use Check App State / element detection to determine whether the Login screen or Home page is present.
However, the Login page and Home page have different window titles, and the titles can also vary between environments.
So my questions are:
What would be the recommended UiPath design for this scenario?
Would you use Check App State, Element Exists, Retry Scope, Parallel, or another approach?
How would you make the selectors reliable when the Login and Home pages have different titles?
Would you handle the environment-specific values through Config.xlsx, or is there a better approach?
I’m interested in hearing how experienced UiPath developers would design this so that the same workflow is stable across environments.
Hi @Abhinay_Reddy1 ,
The most reliable approach is to launch the application and then use Check App State to determine whether the Login page or Home page appears. If the Login page is detected, enter credentials and continue. If the Home page is detected (SSO), skip the login step and proceed directly to the business process.
Best practices:
Use stable selectors based on unique elements, not window titles, since titles can vary across environments.
Store environment-specific values (URLs, credentials, selectors if needed) in Config.xlsx/Assets.
Use Check App State + Retry Scope for robust detection instead of hardcoded delays.
Keep the login logic in a separate workflow so the same automation works in DEV, UAT, and PROD.
Thanks for the detailed explanation. One question — would Parallel Activity also be a suitable approach here, where we check for the Login page and Home page simultaneously?
Yes, Parallel can work, but I would generally prefer Check App State for this scenario.
Check App State is simpler, easier to maintain, and designed specifically for handling multiple possible UI states.
Parallel is useful when both checks may take time and you want to react to whichever screen appears first.
Using Parallel can add unnecessary complexity if you’re only deciding between Login Page and Home Page.
Where to use Parallel:
Page load behavior is inconsistent.
Login and Home pages can appear after varying delays.
You need to monitor multiple possible screens (Login, Home, Error, MFA prompt, etc.) simultaneously.
For most SSO vs non-SSO scenarios, Check App State + reliable selectors + Config/Assets for environment settings is the cleanest and most maintainable design.
You can use a Pick activity with separate Pick Branches for the Login screen and the Home page. Whichever screen appears first triggers its branch, so the bot logs in only when the Login screen actually shows up.
If this login setup is shared across multiple processes, I’d recommend moving the login logic into a reusable library and installing that package in each process. So, you will create separate workflows for each environment in the library. You can then create an Orchestrator Asset (for example, Environment with values DEV, QA or PROD) in each environment’s folder. Pass it to your project and based on that you execute respective library activity. This keeps the logic in one place, so any change is made once and picked up by every process after a package update.
Even in SSO environments, it’s worth adding a quick check for the Home page before continuing. If SSO fails or a session expires, the Login screen can still appear, and it’s better to throw a clear exception than to fail later in the process. This approach reduces unnecessary Check App State activities which takes time for checking.
Here’s my 2 cents.
Instead of relying on Check App State to determine in which environment we are, I would add something like an input argument to my process, let’s call it in_Environment and set it to DEV/TEST/PROD.
Then based on that launch app login logic or not.
Definitely wouldn’t use Pick Branch in this scenario. Initially I liked this activity due to how flexible it is, but now I only use it as a last resort, when there are several scenarios possible and there is relatively long delay, so then it’s better than sequence of Check App State activities.
@Abhinay_Reddy1
I’d make the authentication flow configuration-driven. For example, keep an AuthMode value in Config or Orchestrator: DEV/UAT = Credentials and PROD = SSO. In Init, read that value and invoke the login workflow only when needed. I’d still add a quick Check App State first so the robot doesn’t try to log in again if a valid session already exists.
For this kind of scenario, you can use Incognito mode, which gives you a fresh login session each time. If Incognito does not work because the application does not support it, you can use the Pick activity to check both conditions and let the bot select the appropriate branch.
The Login page and Home page will have different titles, so you can use Check App State to identify the current page.
Regarding environment-specific titles, when developing, make sure the title or selector does not contain a fixed environment value such as APP1-UAT or APP1-PROD. In this case, make the selector dynamic so the bot can handle different environments.
You should also check for environment-specific values in Assets.
If this resolves your query, please mark this answer as the solution.
We generally go with using a parallel activity …and use multiple check app states and depending on that we choose which path to go with…
Also another way we use for few is when sso is there generally the URL would be sso url not the actual application…but in lower env without sso it would be normal url so we use an if condition to check if its sso url or not and proceed accordingly
I would also recommend this approach, I’m also using same in my current project, and if you will use multiple check app state activity then it can increase delay time to check the screen.