Configuration Settings

This lesson is part of the course UiPath Automation Coding Standards . Use navigation on the left.

When automating processes, we will inevitably need to use configurations. We can categorize the configurations into the following groups:

Configurations for which the values never change

Examples here would include a static selector, or a label in an application. These ones should be hardcoded in the workflows. There is not even a long term benefit from going through the trouble of storing them in a file.

Configurations that are highly unlikely to change but are used into more than one place

This category could also include settings that are important and are not meant to be changed by someone outside of the development team. To allow extensibility and also increase readability, we recommend to store these settings in a config file. Examples: Log messages, log fields, file or folder paths and patterns. This way, if during development there is a need to change one of these settings, they will be changed only in the config file. This technique also improves readability as the key in the dictionary will have a meaning attached to the actual value (E.g. using the “ReportID” key in the dictionary instead of the actual value: “12361223”)

Configurations that are likely to change from one environment to another

Into this category we have application paths, URLs, queue names, credential names etc. For these settings we recommend using Orchestrator assets. The main advantage in this case is that the values can be changed without modifying the code, so it allows the code developed only in the Dev environment to migrate without changes into Test and then Production.

Runtime settings

These are required to be set during runtime. For Unattended robots we should use Orchestrator assets, queues or external callouts, while for Attended robots, this is achieved through input dialogs that request the necessary information.

Configurations that have different values for different robots

For this category of settings, use Orchestrator assets with per robot value.

In general, the final solution should be extensible, to allow variations and changes in the input data without an intervention from a developer, when required

You might be interested in the following courses:

Course Category

  • UiPath Automation Coding Standards

    by Ajay Kumar Konda

    Coding standards are a collection of rules, guidelines, and best practices. Coding standards are important for safety, security, and reliability. In this course, we learn the most important and UiPath recommended coding standards. Starting from naming conventions to maintaining your code in the code repository, we cover all the best practices.

  • Automation Anywhere Bot Development Best Practices

    by Ajay Kumar Konda

    This is an advanced guide to best practices that need to be followed in developing bots using Automation Anywhere. This course provides an introduction to common bot design guidelines and standards. Avoiding common mistakes and including these processes and considerations in your bot design standards, creates bots that are clean, easier to read, test, maintain, and are stable. Most of […]

  • All You Need To Know About Robotic Process Automation

    by Ajay Kumar Konda

    Robotic Process Automation(RPA) is a kind of automation where a bot performs human’s task in completing rules based jobs. Robotic Process Automation refers to a style of automation where a machine, or computer, mimics a human’s action in completing rules-based tasks. In traditional workflow automation tools, a software developer produces a list of actions to automate a task and interface to […]

Back to: UiPath Automation Coding Standards > Best Practices