It would be helpful if we could put arguments to a release in tab “Release” in Orchestrator to a Process Call
(Perhaps the arguments of the Main.xaml)
or define which xaml is called.
We would like to call different parts of the project with own schedules without splitting the Code in different projects.
How do you solve this request in current versions? Is something like that planned in a future version?
This is similar with assets per environment. We will implement assets per Organization Unit in the next version.
I mean to enter an input argument when starting a job from Orchestrator.
Just to use the same process with small configuration by each job.
e.g.
I would like to create a schedule
Create an asset that looks like this:
Asset Name: “ProcessName_a”
Asset Value “11:00=b - 17:00=c” which you can parse in the workflow. You can store a json in there.
@badita
we do have still a big issue with this topic because every time we have to change the schedules we have to change a lot of assets as well (if we use your workaround).
So in the end we need something new to have the possibilty to start the same robot with e.g. a name of a config file as argument.
At the moment we have to copy the complete Workflow, change name of config file within code and upload to Orchestrator as a new process. Doesn’t make sense anymore 
Is it the same robot(s) running the job with different parameters or they are different?
Same robot.
Best solution would be if you allow to set an argument to the workflow when creating the schedule but you declined this.
I do not find a good workaround
Goal is that project member could easily define their schedules with different input to the provided robot workflow.
I’d so wish to upvote this more than once
Sad thing is, it was possible to send arguments via old Robot API (v8 and 8.1) when starting a robot, you could even get out arguments out of it (in theory - I’ve never actually tried it, but descriptions of it was there).
.
@badita - we have similar use cases, where a robot has different behaviour depending on settings.
Currently we’re dealing with it in assets, but that requires someone to change it between runs (f.e. a “weekend mode” [that includes bank holidays etc.] in one of the projects takes predefined excel queues, while a “normal” run first builds those with humans help).
And this scales extremely poorly with multiple robot deployments of the same process - either you make all of them behave the same, or you’re making all your assets per-robot, which is a major pain to manage.
I’d fully understand limitations to string/int/bool, same as with assets, as it obviously would be pretty hard to set complex types through UI. Heck, even just strings or ints would be enough - we can always add handling to those in the xaml’s and have strict instructions what are the valid args (one can always use an int like a flag enum, which gives a lot of options, even if it’s not most straightforward to use).
I am personally stunned that this capability does not exist.
I don’t consider this an upvote, I consider it an
absolute requirement for the software.
We are creating bots do do a variety of corporate tasks… but every bot requires key input values which differ with every run (eg. Client Name, Answers to Questions, Who to notify when complete, etc).
When we started evaluating UiPath, the Orchestrator was not done yet… but the REST API to the robot gave us faith in what UiPath was doing (it was exactly the solution we needed). We just thought the Orchestrator would add scaling to a robot farm, central management, etc. But to see that capability deprecated now is almost unforgivable? Very bad decision…
We are currently rolling our own solution to deal with this… but not very happy about having to do it. Basically creating a custom extension which will call a service to ask for inputs instantiated on a queue. Bot we SHOULD be able to associate inputs directly with a specific job… not run a job and have it pick randomly off the queue.
I hope this gets addressed ASAP…
Strings are fine… we deal with JSON all the time.
So, assets per release would solve that issue…which we’re considering.
Of course in the new 2017.1 you can enable assets per organization unit (instead of tenant), so deploying the process in different units will give you access to separate assets/queues for that process.
Still wrapping my head around the Orchestrator object model…
What does “release” correspond to?
We need to provide variable argument values to every run of a bot.
If you want to provide variable argument values to every run of a job right now the simplest workaround would be to use queues.
As of now :
Robots
Software robots that automate rules-based processes in the same manner as humans would
Environments
Grouping of robots for deployment purposes
Processes
Process diagrams. Business process definition packages published by developers
Assets
Shared variables or configurations used in processes
Queues
Work queues used to distribute work items to robots
Releases
Distribution of process versions to robot environments
Hi,
Is this thread still open? Has it been consider for development already?
We see this as extremely valuable, must have functionality.
this will next level of flexibility to run jobs with variable argument input when executing a job.
i can give you an example of simple business if you still need it.
Regards,
Nishant
Hi,
Do we have some mechanism in Orchestator 2017.x to provide arguments to jobs.
We have situation that we are executing same XAML couple of times during day and each execution does different things based on argument that is given in start command via Task Scheduler. Is there possibility to do this with Orchestator so that different jobs would have different argument (or different value in same asset) for same one robot?
Bump. Still only on considering…
planned for this year.
YES! GREAT NEWS
Hello UiPath Leaders!
Just wanted to check if UiPath is planning to release this change to allow passing arguments to a job directly through Orchestrator or API calls. The more I work on UiPath projects, more it seems important to have this functionality. All other major RPA vendors allow this currently. Hope this is considered as constructive feedback and addressed soon.
Thanks & Regards!
Planned for 18.3 and it is already in beta.
ashokkarale
lrtetala
postwick
Julian_Muhlbauer
Yoichi
Ajay_Mishra
Anonymouss
vrdabberu
ABHIMANYU_THITE1
anjani_priya