Orchestrator parameters do not work with UiPath Assistant

Feedback Assistant
, , , , ,
#1

Please clarify a little more about this. We aren’t on 20.8 yet and I need to know how this will work. The Process parameters not flowing through to an attended bot started through the task tray is an enormous problem for us. Our use case is that we’re doing away with the clunky Excel config file thing, and using Process/Trigger parameters to store all that. Much cleaner and easier to manage.

But I just tested on our version 2019.10.17 and the parameters do not carry through when I start a Job from my task try icon.

Some questions about the link you just sent.

It says at the top it’s the “20.8 Community” version. Is this new functionality included in the Enterprise version 2020.10.4?

You are able to configure each process from your list by using the input parameters set up in Studio to configure your processes for the next runs

Does this mean the values must exist in the code, in arguments in Studio? Or can we leave those blank and provide the parameter/argument values in Orchestrator?

From this link: UiPath Community 20.8 Preview Release

You can set values for input arguments directly from the UiPath Assistant

Is this different from setting the Process parameters in Orchestrator? From what I understand, UiPath Assistant runs on the user’s desktop. Does that mean each user would have to manually enter the parameters for the Process?

WE NEED THE PROCESS PARAMETERS ENTERED IN ORCHESTRATOR TO FLOW THROUGH TO AN ATTENDED BOT STARTED THROUGH THE TASK TRAY ICON

Is that possible now, or not? If not, this is an enormous oversight by your team and needs to be fixed.

Orchestrator Process Parameters not passing to attended robot
#3

So we upgraded to 2020.10.4 Orchestrator and 2020.10.2 Studio/Assistant.

Now Assistant shows the parameter value as set in Orchestrator. But when you run the bot it doesn’t actually USE that value. It still gets the value from in the code/Studio.

Yes, that’s right - even though it shows you the parameter value as configured in Orchestrator, it doesn’t actually USE that value. Ridiculous.

If you manually CHANGE the value in Assistant, then it uses the value you put into Assistant.

Of course that’s not good either. We don’t want end users to be able to see and change these things. This is very, very poor design, lacks common sense and solid usability.

Hopefully there’s a way to prevent users from seeing, or at least changing, parameter values.

1 Like
#5

Thank you for your feedback @postwick
I moved your post to our dedicated category for feedback and bug reports, and we will look into it. I tested it on my end and it is indeed strange that the Orchestrator argument is not picked up by Assistant correctly.

#6

Please note that there needs to be a way to prevent users from changing the parameters. I can see some ways it would be useful, but it shouldn’t be a default. It should be something we can turn on/off. In fact, being able to set it per parameter would be great - allow them to change some parameters but not others depending upon the situation.

1 Like
#7

Thank you for your suggestions. I included it in the ticket.
I’ll keep updating this topic when more information becomes available. Please keep in mind that there might be a bug fix component and a new feature component to this, which means that eventual bug fixes might precede an eventual extension of the functionality, which would be added to our roadmap.

#8

Is there any update on this issue? I am using 20.10.6 and notice that the argument values must be edited in Assistant before they “take” are and get used when you run the automation. This is confusing to users as we must explain to all Assistant users that they need to go edit the displayed value of the argument (add a space at the end, or whatever) before it will actually be used when they run the automation.

2 Likes
Forum Engagement Daily Reports
#9

It is currently being investigated. I will share more information when it becomes available :slight_smile:

#10

Starting from 21.4, Assistant now allows to push the arguments from Orchestrator.

1 Like
#11

Any word on being able to prevent users from seeing or changing the arguments/parameters?

UiPath making a blanket change like this that dramatically changes how things function is really bad. You have to be more careful about things. You have some customers like us where these things matter - specifically, regulated industries where compliance is up our you know what about everything. Didn’t anyone there consider that allowing users to change these things could cause a security breach? Say we have a parameter where we put in an email address to email confirmations that include things like bank account numbers. If a user is able to change it, they could cause that confirmation to be emailed outside our organization which is a MASSIVE regulatory violation.

1 Like
#12

To be specific, a setting on the Process parameters tab where we can select “allow users to see parameters in Assistant” or “do not allow users to see parameters in assistant” would fix the issue. A parameter-by-parameter setting could allow more flexibility but at the cost of more administrative overhead.

1 Like
#13

Hi @postwick,

Sorry for the fact that this feature broke your processes. I would suggest, as a workaround for you to either use:

  • an array of strings or another complex type that we’re not showing in the Assistant (we only show numbers, strings, boolean, and DateTime). I.e: have the parameter changed from String to String[] and instead of using the arg as is, you can create an assign at the beginning with arg = argArray[0]
  • or an asset through which you control the passing of the info to the process. This may not be feasible depending on your current set up
#14

Thank you for the suggestions. Please let me know if we can expect to have some options for parameters so we can control what end users do and do not see.

#15

Hello Paul,

thank you for addressing this - I just updated my Studio/Assistant-Version to 2020.10.6 and was shocked to see the arguments pop up. I mean… to be honest, it’s a great feature, but without differentiation between arguments the user can manipulate and arguments the developer can define it’s horrible.
Giving the process the needed configuration via parameter is way better than directly program it in the code or some config-table, because then you don’t need to change the code every time you want to change the configuration…

1 Like
#16

For now we are still using a config Excel file for attended processes. However, what we do is store the Excel file on a secure network share, outside the scope of the process code. Then we define an Asset in Orchestrator containing the path to the config file, and use that Asset’s value in our “read config file” steps in our code. This way, we can edit the config.xlsx file without having to re-publish the process.

However, in general using a config file is clunky and causes extra steps (and points of failure) within a process. As you stated, using parameters is MUCH easier, cleaner, more efficient, etc. It’s one of the reasons I think their REFramework is awful and I never use it. I built my own “framework” and it’s much cleaner and more efficient.

#17

Hello,

  1. I just tried using complex datatypes but this does not work. You cannot set the arguments (of complex types) via Orchestrator, because they are simply ignored by the Process (we are in the UiPath Cloud, Assistant 20.10.6) Main.xaml (6.5 KB)
  2. If you only have a required complex datatype, the Assistant prompts for the input, even though it shouldn’t and you can’t press “Save”:
    image
    If you enable and disable PIP, you can press “Save”, but still - that’s a bug as well.

Which means, if I want to create two processes with different configurations of the same package, I can’t do it without simple datatypes and the user being prompted for input/user being able to change the values.

1 Like