Environments and Environment Variables are designed to allow easy and consistent transfer of Workflows between a development or building System and into a production System, to centralise the management of externally-controlled details, and also to protect sensitive details such as API keys or other credentials from being exposed to agents or Users with Designer licence parts.

 

Environment Variables can only be used at specific points in the configuration of a selection of Controls, being more restricted than the use of Fields and Variables so as to prevent their contents being exposed to agents or Users with the Designer licence part via simple reflection or display of the Environment Variable.

 

Once an Environment has been created and some Environment Variables added and configured, then it will be usable in Workflows in a similar way to Fields and Variables, albeit with greater restrictions. You cannot, for example, use an Environment Variable within a Text Label as this would cause its content to be exposed to non-System Manager Users. It is also not possible to edit the value of an Environment Variable from within a Workflow, as their values are solely controlled by the Environments Section.

 

Generally speaking, Environment Variables will only be usable when they are offered in a picker, such as when configuring the Service URL in a web service datasource. Simply select the desired Environment Variable from the bottom of the picker list if you wish to use the Environment Variable for the entire value:

 

 

...or manually type the name within {{double braces}} if you wish to use it as a portion of a larger value:

 

 

If there is a common detail that is used across multiple Workflows, then it is also possible to centralise the management and configuration of this by the use of an Environment Variable. This might be done by all of the Workflows making use of a shared Environment, but may also be a case of using multiple Environments for different Workflows but still speeding up the locating and updating of the details to just the Environments Section.

 

As an example, if all of your Workflows make use of an API, then it may be useful to store the root of the endpoint as an Environment Variable. This means that there won't be issues with typos in individual Workflows or Fields causing unexpected failures, and should the endpoint need to change in future (due to a rebranding or relocation), then this simplifies the work of updating all Workflows to use the new endpoint.

 

 

One of the features of Environments is that they form their linkage based on name. This means that if you build a Workflow that makes use of an Environment in one System, then if you export the Workflow and import it onto a different System that has an Environment with a matching name, then the imported Workflow will be able to use its Environment Variables without any further changes being required.

 

As an example, if you are building Workflows in a development System it may be that you need to use a development API endpoint and credentials for the initial testing phase, but want to use the production API endpoint and credentials when it has been imported to the production System. Previously, you would have had to update all relevant Fields or Variables to adjust these details manually, which incurred a risk of a mistake or typo causing a new Workflow to malfunction.

 

 

The benefit of Environment Variables taking immediate effect over any assigned Workflows also serves as a risk, as any careless actions in the Environments Section run the risk of impacting many Workflows - including Published Workflows that are currently in use by agents. Below are some specific points for awareness: