Bot Labels And Selecting Config Version

Question

We do not currently use bot labels (Assign label to a bot).

As a bot developer in a controlled corporate environment, I do not have the ability to experiment with this feature.

However, after reading the documentation, I believe that bot labels may be able to solve an issue we experience and I am looking for advice and expertise from those who use bot labels.

The problem: we have a standard bot development cycle which goes from Dev to UAT to Prod environments. In the UAT environment we perform the majority of testing over test data. However, we often run bots over production data in UAT as a final step before promoting to Prod. Due to the fact that UAT uniquely runs over both production and test data, our config file (which stores the “test = TRUE/FALSE” variable) has to be updated via tedious promotion several times.

The Possible Solution: after reading about bot labels, I now suspect that instead of having to promote a brand new config file from Test to UAT every time we need to switch the data sources, that we could just create a TEST and a PROD label for the two different versions of the config file living in the UAT repository. So (with my limited understanding), in theory, when we need to run a bot in UAT over test data, we could simply select the TEST label at run time and the bot will use the config with test flag = TRUE. Vice versa for production data.

For those with experience, can you please let me know if this would work and where I might be off base?

Padmakumar · Accepted Answer

Hi ​@LoganPrice,Bot labels in Automation Anywhere are mainly for version control and stable execution references, not for dynamically switching config files. They won’t automatically pick config_TEST.json vs config_PROD.json at runtime. Your idea is close, but labels alone won’t solve the problem.The simplest solution is to add a run-time input variable (e.g., dataSource = TEST|PROD) and keep both config files in UAT. The bot reads the correct file based on that variable, avoiding repeated promotions. Combine this with Credential Vault or Global Values for endpoints/secrets to make switching safer and cleaner.If you want labels involved, they’re best used for bot version pinning or modular config providers—not for toggling files. Add guardrails for PROD runs in UAT (confirmation token, audit logs) to prevent accidental misuse.

Uzumaki · Answer

Hi Logan,I don’t know if this will 100% answer the question that you’re trying to find, but I’ll try anyway. In our environment, also a corporate environment with the dev, qa, and prod lifecycles, we have a single config file that handles the data for all three environments. The config file has tags for dev, qa, and prod. Inside of our automation anywhere control rooms we have a global variable, $@enviornment$, that is equal to our current environment. So in the dev environment, it equals dev, in qa its qa, and in prod its prod prod.So essentially when the bot runs we don't have to specify anything to have it access environment specific data, it just opens the config file and grabs the data from config where the environment tag matches our current control room environment.Like I said earlier, our config file is a .yaml file. We have a global bot in the control room that is called by all of our task bots thatconverts the yaml to a dictionary so that we can easily access the config variables from within the bots. An example of our config file might look something like this:dev:  projectFolder: \projectfolder\dev\myproject  processName: AR financing  logLevel: info  emailToList: 'myemaildev@email.com'qa:  projectFolder: \projectfolder\qa\myproject  processName: AR financing  logLevel: info  emailToList: 'myemailqa@email.com'prod:  projectFolder: \projectfolder\prod\myproject  processName: AR financing  logLevel: info  emailToList: 'myemail@email.com'Hope this helps. If not, let me know.

Sign up

Login to the Pathfinder Community

Scanning file for viruses.

This file cannot be downloaded