Who's gonna start the Orchestration Process?

Hi. The topic seems like a simple question I guess but that’s something I can’t comprehend about Orchestration Process. Suppose you’ve created and published an Orchestration Process to the Orchestrator, who is the person (or the system) responsible to start that process? It’s a long-running workflow, but one must eventually start it, correct? Would you please elaborate the subject? Thank you.

Hy @atoi,

If you connect your robot to the orchestrator and upload you process there, there are two types of execution.

Attended: go to the uipath Assistant and click play to run. The end user will start
Unattended robot: the bot will execute automatically with out user intervention. This execution is scheduled in the orchestrator

Please check documentation
https://docs.uipath.com/orchestrator

Is it clear to you?

Regards

Yes it is clear but that was not the answer I was looking for. My point is about the rationale behind this specific type of process, Orchestration Process. It controls the overall process execution and coordination of tasks, jobs and queues. It defines what robots start and stop.
But what about the Orchestration Process robot itself. How’s the scheduling supposed to work? Who’s gonna control the execution of the Orchestration Process Robot itself? Is it like a robot that controls another robots?

Hy @atoi,

Please check links about scheduling:

One setup its done. It will start and run automatically as scheduled. It Controls and monitors all robots

Regards

@William_Blech_Sister I am well aware of the Schedules feature (now’s called Triggers in Orchestrator). I’m asking about the rationale, about the mindset behind it so I can make my own.

Hi @atoi : Orchestration process is intended to help end-to-end process automation by stitching or orchestrating multiple RPA workflows (through start job or queue item) as well as human actions (create form task, create document validation action etc).

This process is intended to be an un-attended process and bring humans in to the loop only when Robots needed assistance. So in all practical scenarios, this is yet another regular process scheduled in Orchestrator which has additional two states (suspended and resumed) that indicates that the workflow can be long running in nature awaiting for an underlying process or human action to complete before proceeding. But ensuring that the Robot that is executing an orchestration process is freed up, available to pick another job while a workflow is in suspended state.

It will be a just-in time auto-resume(handled by orchestrator, which is the key factor to avoid Robots continuous polling) as and when underlying process/action gets completed and the suspended workflow will resume from the step where it got suspended (with any relevant input/business data from underlying process/action transferred to the resumed workflow)