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