Asset per environment (type)



We use different Environment types in Orchestrator– Dev/Test/Prod.
But for each Environment some variables in UiPath Workflow code should be defined with another value.
E.g. the URL of the application changes in these environments.
Other example : we would like to use an own queue for each environment type.
So: Is it possible to check Orchestrator Environment Type within UiPath workflow code at runtime?
Other idea would be to add an asset not only per robot but also per environment type or environment.
How would you solve this requirement in UiPath code in current versions?
We would like to use the same process with other input parameters per each environment (type).


In current version - only with a combination of PerRobot flag assets that would decide which assets it takes later, unless someone has a better solution. Essentially you’d need to emulate a branching config file.

But the functionality you’ve described as far as I know is planned for a future release (to be exact - Assets/Queues per Release).


We’re aware that this will be a really useful feature and it will come in 2017.1.

Therefore it will be possible to associate assets and queues with an environment. At runtime you have access to

  • the robot that is running the process
  • the process itself
    therefore the server will know the environment within a process is running.

This comes with a very small limitation. A robot will be associated in only one environment.

Currently, the only way to mitigate this is by using a mapping config file containing robots and environments and running GetEnvironmentVariable(MachineName) or GetEnvironmentVariable(UserName) to determine your runtime environment.


Is this feature available in Ver 8 (2016.2.6192 ), we have the same requirement whih b_s has mentioned
if so how to implement the same, thank you


No. In 2017.1 Assets per Organisation Unit will be available.


Could you confirm what will be the end result of the Assets per […] in 2017.X?

There are a couple of Idea topics about it, each slightly different and the conclusions drawn could vary. Since 2017.1 is drawing near, we’d prefer to ease the transition workload and also for newer projects make sure they aren’t a pain to migrate :wink:


Org Units will be similar to tenants but without the need to login when switching between them. Assets and queues will belong to only one Organisation Unit