Human Computer Process Interaction for Back Office Robots



Hi there,

today I miss the opportunity to pass a (back office robot) process back to a user to gain additional information. Sometimes our customers have workflow systems where this can easily be achieved but very often they don’t.

My vision is that I can model a (simplified) business process (for example in a web tool or the orchestrator). This process involves multiple sub processes. Some of these sub processes can be executed by robots, but some of them require humans (or are just not fully automated).

For example the trigger for the process could be a human who requests . So we need i.e. a little web form where the user can submit all the required data, that are needed for the process. The data from the user is passed to a robot/rpa-process which does everything what he has been told to do. At a certain point a human interaction is mandatory before the process can continue. For example a certain approval or additional data. So the robot passes the process back to the user. The user (i.E. approver) logs in to this tool and can see that there are x (maybe different) processes which requires his attention. He can see all the process data. Then he does what he needs to do and passes the necessary additional information back to the process. Now a (maybe different) robot will continue to work on the business process. As soon as he needs further input, depending on the business process, the robot will eventually ask again for a user/team to do some human work until the business process is finished. So it is a ping-pong between user and robot.

At the end we would be able to see and analyse for example:

  • how long the business processes take end to end
  • how often the business processes are called
  • which human sub processes take the most time during the business processes (this might be the next sub processes to automate)

In terms of software development this idea is surely kind of a “epic” because it has a lot of implications. I wrote just the tip of the iceberg what I want to have :slight_smile:

Maybe there is also a good way to integrate existing bpmn or workflow management software.


Pause, Stop, Rewind to an activity based on user approval
UiPath for the development of quickwin/interactive applications / can UiPath provide GUI

Hey Thorsten

Have you thought about using email as a means to achieve that human-robot interaction?
Basically when the robot reaches a point where it needs a human action, it sends all the necesary decision information by email to a human.
It also monitors the inbox for incoming messages, and when a person responds with the decision, it parses the email, extracts the decision, and continues the process.


Hi Cosin,

sure and I also did things like that. But it get’s complicated quickly, i.e. if I need multiple informations from the user which also should better be validated before the robot starts to work with it. The user has to know exactly how to respond correctly to the email. Also it is hard to work with a team of people (what happens if multiple people respond) etc. Furthermore it is hard to monitor the whole process and have a nice overview of everything. Further further more, if I later decide to automate the human part, I will have to rebuild my processes or I will have Robots which sends mail to each other - which sounds not really elegant to me.

I also programmed a web interface which can easily be set up to submit items to a orchestrator queue. But I would love to have a full blown bpmn/workflow tool which allows me to track whole business processes and provide HCI easily.



It definitely makes sense. So we’re actually talking here about 3 features

  1. the ability to chain processes (a business process is made of multiple subprocesses
  • FO - requires human interaction and
  • BO - unattended
  1. the ability of having customized input forms for FO interactions
  1. the ability of assigning FO work items to humans

We’re definitely looking into 1 and 2 on medium term (1year).

Point 3 gets more complicated and we need to decide on the direction we move on

  • we do offer this functionality out of the box in Orchestrator
  • we do offer and improve the way Orchestrator integrates with other workflow tools (BPM, DCM, etc) in which case the FO interaction, data inputs, etc will happen in an external system and then an UiPath (sub)process will be triggered via API.

Somehow I feel that the last option makes more sense since these systems already resides in an enterprise infrastructure. In time we could do both and offer a lightweight workflow tool in UiPath but it will take time.


I don’t know if this is the best solution, but what if you had a file/script/exe that is called over the network to run on the user’s computer via Powershell or something, and that file can be a form or something so the user can input the data that is needed and it updates a spreadsheet or text-based file. Then, the UiPath robot is waiting for certain data to know that it has been updated or by modified date.

You could also just simply have them update the spreadsheet after the robot emails them and then that update triggers the UiPath robot to continue, similar to above idea but no form.

Sounds like there are ideas floating around from UiPath team on features down the road, though.



Thank you so much for your input @badita and @ClaytonM! I really like your ideas. But just to clarify a little bit: I know that there are some technical ways to work around my requirements, like with scripts, excel files, mails etc. But what I imagine is to have a enterprise solution which is state of the art and brings RPA to the next level where BPM and RPA are kind of blended up.

@badita: concerning Point 3: I would love to have this kind of lightweight workflow tool in UiPath. I already explored and worked with some of the BPM and workflow management solutions on the market but there is no perfect fit. I am totally aware that this is not something to expect within the next year. But if I won’t get something like that in the next 2-5 years (in small steps) I will build it on my own and sell it for a lot of money :wink:


We’re using that internally with help of Orchestrator API to have better process modularity. It works quite nicely, but still feels like a hack :confused:

This I don’t agree with. Or rather I don’t have anything against integrating with BPM etc. but that would also lock people out (not all enterprises use them and they can get costly, it’s splitting visibility etc.).

For a lightweight solution you “only” need:

  • A new segment in Orchestrator (let’s say “Work Items”), with separate access right (similar to Logs, Packages etc.)
  • Ability to add a form to the Orchestrator and link it to 2 queues - input Queue and output Queue
  • That form works similarly to a robot - take item from queue, provide output, confirm and send to robot/confirm and send to human/reject
  • Forms could be defined as a mapping of SpecificData to fields and fields to SpecificData and would be static for a set queue trio (input/robot output/human output)
  • Reject would work same as BusinessRuleException (user provides reason)
  • Both accepts work as Successfull, but send Output data to different, predefined queues

Something like this (ugly, I know :wink: ):

Input queue SpecificData fields: CustomerID, CustomerEmail, CustomerRequest
Output queues SpecificData fields: CustomerID, CustomerEmail, CustomerRequest, HasOverduePayments, RequestType, OrderedItem

The last human queue processing could be handled the same way, only that it doesn’t send data further - it ends there. Reporting would also be so much easier if both human and robot work outputs could be just taken from the queues and not stitched together afterwards.

It would be basic and require form designer (possibly separate), but hey, it’s lightweight.
And it could benefit from integrated logins with Orchestrator, which is already in place, as well as being official (as in - won’t break with next update) - which are the main points that are missing now - direct integration with authorization and being part of the platform, not a tacked on workaround.