V2018.2 Beta release


How to convert a text string to StanfordCoreNlPSentence Object? Don’t see documentation for this activity on https://activities.uipath.com/docs


It’s the small things that make me happy :slight_smile:

I’m also really curious to see the “Enhanced Variable Watcher” in action


Hi @KapilKathuria

There is no documentation yet because this is a Beta release. When the official release will come we will have them documented.

I don’t see the point in doing this. The idea here is to analyze a text with Text analysis activity - the output here would be a List of StanfordCoreNlpSentence. Then iterate through that list (For each activity) and the Sentence you need would be the item in For each.


Yup Thorsten, I feel you :blush:

Try it on Studio beta and let us know what you think.


Hi Team,
What is the plan to rollout the stable version of v2018.2. We are in process of onboarding uipath orchesterator for one important client.


Hi Amit,

Check out Badita’s answer in this post:


Thanks Badita!!! This is great. Is there any road map about the new features in the given versions?


Thanks i got the features for 18.2


Hi @ovi,

Can you please help me understand what is runtime in this scenario?

I would like to know if this credentials being assigned to the robot at runtime based on the process, in other words, assets per package to store the credentials to execute the robot.

Thank you.


@PD2 - An example in our deployment - we provision multiple robots (using high density robots) on a single Virtual Machine workstation (Win7 enterprise in our case) for unattended execution to allow us to use different IDs across different processes. This allows us to improve the utilization rates of our VMs - since we have some processes which only run monthly or quarterly. (We asked for a feature which would allow us to do an ID per process… but that is probably quite far away!)

The problem (and why we are excited about this feature) is that Win7 enterprise only permits one concurrent user runtime. Before 2018.2 the behavior was that if you trigger a process while a process is already running on the same robot, the new process gets into a Job Queue (pending) however if you trigger a process on a different robot on the same VM while a process is already running the newly triggered job fails.

FWIW - We cannot move to server versions of Windows because our business applications are not ‘certified’ by IT to run on that OS… And running all processes under a single ID creates security risks – you end up with a super powerful single user ID that has the keys to the kingdom pretty quickly.


Hi Jose,

Nice approach, that trigger me a completely different question in my mind. Would you mind sharing how the license was applied to the high density robots? My understanding is that when we install the robot on the server there is only one UiRobot.exe at the Program Files level right?

Fair enough, this is a limitation of Windows and not UiPath.

I’m assuming that it is because the UiRobot.exe is still one executable files being triggered multiple times by different credentials.
So the feature of having Runtime defined in orchestrator helps solve the issue of not failing if another process is running, is my understanding correct?

Thank you,


Hi Priya,

As of right now each additional provisioned robot consumes a license even though they cannot run in parallel. We will explore how concurrent license model with single runtime may work, to adjust our licenses.

Correct - I have not tested the implementation yet, but my assumption is that orchestrator will check how many available runtimes there are on the VM and even if a ‘Robot’ is available to run a process, but a ‘runtime’ is not, it will add the job to the Queue until a runtime becomes available to launch the robot to execute the process.


Thank you Jose that helps me understand the scenario better.
We have one unattended bot running multiple processes and the bot runs with one credential having access to run all the processes. That’s the reason I was looking for configuring credentials per package.


1 Like

Hello @Enterprise

@Mr_JDavey developed a process on this version but when trying to work with it in 2018.1.2 (Enterprise) the Invoke Workflow File Activities all display as XAML Errors. Tried adding all packages including v7 compatibility pack but no joy.

Could you check please?



Hi there all,
Following on from what @richarddenton has noted above, the issue appears to relate to the addition of a timeout parameter within the Invoke Workflow File activity:

  • <ui:InvokeWorkflowFile ContinueOnError="{x:Null}" Timeout="{x:Null}" DisplayName=“Invoke InitAllSettings workflow” sap2010:WorkflowViewState.IdRef=“InvokeWorkflowFile_12” UnSafe=“False” WorkflowFileName=“Framework\InitAllSettings.xaml”>

Removing this rectifies the issue for earlier versions.

Thanks in advance,


update : Nevermind @Mr_JDavey found the issue.

This could be the issue, timeout does not exisit in 2018.1


Thanks for pointing this one out, guys. We’re investigating and I’ll keep you updated. :slight_smile:


Yes that is indeed the case, this new functionality of the Invoke Workflow activity is not backwards compatible with versions older than 18.2 (although older workflows which contain the Invoke Workflow activity will work just fine on 18.2 and up). As pointed out by @Mr_JDavey removing the Timeout="" property manually from the .xaml will make the workflow work on older versions as well.


We call this forward compatibility and we don’t guarantee it. It’s impossible for old environments to know or ignore new properties.
Backward compatibility is when a new version supports old workflows and this is valid for 18.2 release.