Maybe I’m missing something, but couldn’t you already do this? The CustomInput form, to my knowledge, is able to give output from user interactions. Couldn’t that output be used with the current Add Queue Item activity to do what you’re suggesting?
The reason that I am afraid what you’re asking for may not make sense because the user data would likely need to be parsed into a queue item, too. So if the user enters some data into a field, maybe you want to verify and process it a bit first before actually adding it to a queue.
Well what I’m talking about is that all existing interactions require running robot as a bridge between human and orchestrator.
The point is to allow users to start/dispatch robot on demand without having the studio/robot installed.
In my organization we have a lot of RPA processes where user is filling a form and the output serves as a transaction item. The form is used by 2k+ people and none of them has robot/studio installed. It’s easy to manage, but cumbersome for developing fast solutions, because it requires a 3rd party BPMS where robot has to look for a new item all the time.
I think about generating interactive web or application forms that could run Studio/Robot independently but able to power the Orchestrator with queue items through api.
This could be used directly by customers/employees/etc.
That sounds like you’re going outside the purview of RPA though. You’re talking about developing systems for your processes instead of emulating the steps of an existing process. At that point, your company may want to look at more permanent solutions.
UiPath forms are simply a way of representing html-based information. Instead of using it, you could create another web service and then use the web api to add that information to a queue if you’re sure that’s the right way to go for your situation: SOLVED Pushing items to Orchestrator Queue via Web API
This is the situation where you need to embrace the process where entry point is dispersed among hundreds of operators, and there is no way to build a business case with providing everyone with an attended robot.
After the entry point the process is carried out by the unattended robot. This makes much more sense than creating a dispatcher robot that constantly monitors mailboxes, network locations, applications etc just to create a queue item.
There is always a question how to fuel robot with data in such cases.
This will mean that we’ll need to maintain and support a new product: “Forms”. Then you’ll need to deploy it and configure. To post an item in queue the user needs to be authenticated and to have proper authorization on Orchestrator. Maybe at a later stage in the future, I feel somehow that it is not the right moment now, but after we’ll improve the attended maybe we’ll be able to provide different types of functionality on top: attended run, attended forms, attended tasks, etc.
How about making this part of the Orchestrator itself (now that we have queue schemas)
Let’s say your queue does have a schema, a queue-specific URL like the following one could present you with a form (rather than the entire Orchestrator UI) to allow user input (iframe could be embedded in other webviews, emails, whatever) https://platform.uipath.com/bob/alice/queues/123456/add
The only part we really need to agree about is authentication: any action on Orchestrator needs to be traced back to a user, which means that whoever has access to this is also an Orchestrator user.
We have a workflow in development which is very similar, where tens or even hundreds of people should be able to request work items. It seems easiest to me to do this with a Form, and make this form put the specified items in a queue.
Going through Microsoft Flow or similar would work but then we’re adding an unnecessary step to the process, since I feel it would be easier to have this functionality inside of Orchestrator.
Thank you! This is indeed how we will probably solve it. However, as I said this will involve an extra step which I feel isn’t necessary.
Since UiPath already has the API connections for Queues available, it would be a good extra function to provide easily accessible calls to this API through forms, so we don’t have to worry about an extra set of user roles & permission accesses with the third party form.