Ideal Process Design for Document Understanding with Action Center

Hello All,

What could be the best solution design to implement DU process flow which works with Action center to consider Human input for validation but Bot should not keep waiting (or should not be long running) till gets any input from Human, bot should be able to work with next doc in queue and resume back to last doc as soon as the action gets completed.

UiPath provides a template to build robots with Document Understanding, integrated with Action Center. More info here: Document Understanding - Document Understanding Process: Studio Template (

Thank you, yes I have used this template, however it does not allow to resume with next doc until other doc is in suspend mode, I am moreover looking to utilize bot fully, if there are few actions pending in action center, I don/t want Bot to be in suspended mode, but to work with some other doc from queue

@nisha.sonawane just to clarify:

  1. When the bot is running (i.e. a Job is created in Orchestrator), when creates the Task in Action Center, the Job status changes to Suspended.
  2. When the Job status is Suspended, the unattended robot PC is free to take on other jobs
  3. When the Task is completed, the Job resumes if and when the unattended robot PC is available (i.e. not running other jobs).

So that meets your requirements, doesn’t it? , thank you for the details, correct if I am wrong, so with given template even if one job/doc gets into pending/ suspended state for action, the bot still can go ahead and pick up the next job/doc and work with it?

Hi @nisha.sonawane ,

Here, Adding on to the points already mentioned above, we would need to understand the whole Process Design.

Then Based on Process, we’ll have to Segment the Process into parts, Where one part would be to have the DU/Action Center process as a Separate and then the Post Process of Action Center part as separate.

So, now we have two processes which acts kind of like Dispatcher and Performer.

In the Dispatcher or DU process, we assess whether there is a need for action center for that particular ticket or item, if needed we send it to Actions else we would want to process that ticket/item completely, Hence here, we trigger the Second Half of the Process which is created separately (Queue Trigger / Start Job can be used) passing also the details of the Ticket/Item.

We do this split up of processes into Dispatcher and Performer for Foreground related operations involving Action center/DU.

For Background related tasks, we should be able to use the same DU/Action Center (Dispatcher) process to complete the other remaining tasks.

Thank you so much @supermanPunch so basically, two process will be in picture, the 1st one will most of the time will go with regular flow of all DU activities/ components, as soon as there is stage where we need to create an action for human, that item/job/doc can be added queue(some other queue Q2), which in turn will trigger the 2nd process which will handle this part of creating action in action center, waiting for it, resuming back once the action is done along with passing some output parameter for the details of action, mean while the 1st process can take other part of continuing with fetching new item/job/doc/ from queue Q1.


@nisha.sonawane ,

There maybe slight change in the understanding. We do keep the Framework or Design as follows :

  1. The DU and Action Center part in the Same Process. Single Process
  2. If we have Post Processing to be done, we Segment it as a Separate Process. If action Center is not needed for the transaction item we continue the process by Triggering the Next part of the Process using Queue / Start Job Triggers.
  3. If action center is needed, then it creates the action and waits for the user to complete the action, and then resumes the workflow and continues the process to trigger the next part.

So, from the above, we see that for those transactions where action approval is required, it doesn’t hinder the other transactions where there is no action approval required as we have a process triggered separately which does next steps of the process.

The below is just a Skeleton of the Design :

The Create Document Validation Action & Wait for Document Validation Action Resume are coupled together so that only when action is required it goes to that block, when it is not required it triggers the next sub process.

Thanks again @supermanPunch for explaining detail, however if 1st doc itself needs action it will be in wait stage, bot will be waiting for action and can not proceed ahead with next doc (and in case there is no reply/ no action lets consider for more than 5 hrs) bot will be in that state only, this may happen in loop for 2-3 doc continuously

@nisha.sonawane ,

Only The First doc will be in the Waiting Stage, You can also check that DU Template uses Parallel For Each which helps in parallel execution and thus the items which would require the Action Center will only be in the waiting stage and other items would continue next parts of the process.

If using DU Template, check the Process Each Document part, it is a Parallel For Each activity.

So the UiPath DU template works this way:

  1. You need to separately build a Dispatcher robot (not part of the template) to upload the file paths of the documents to be processed into a Queue
  2. The DU process template will then fetch items from the queue to process through DU
  3. If human validation is required, the template will create a task in Action Center
    → At this point, the Job status in Orchestrator becomes Suspended. More information about the Suspended state can be found here: Orchestrator - Job States (
    → The unattended robot status becomes Available. More information here: Orchestrator - Robot Statuses (
  4. While the Job is in Suspended state, the unattended robot can continue to process subsequent documents from the queue
  5. Once the task is completed, the Job is resumed, and the unattended robot continues the downstream process from wherever it paused previously.

Note that the above process assumes that:

  1. You’re using an unattended robot for the process. There’s no “wait and process next doc” if you’re using attended robots.
  2. You’re using a queue to keep the file paths, and that queue serves as a trigger to start the performer process described here.
1 Like

Thank you helpful!

So with attended mode, it will be long running flow if Wait and resume activity used.

I’m not sure how an action center task would work with attended robots - probably the robot would just be busy and be unable to accept additional jobs until the task is completed. You should only use Action Center with Unattended Robots.

Action Center - Introduction (

Yes, this is true

Hi @nisha.sonawane

There is one solution for your query, You will have to tweak the template a bit.

Step 1 : Create a list of action object, every time a action task is created add that action object to a list.
Step 2 : Keep the wait for validation action out the initial setup.
Step 3 : Build a loop to iterate through action object list created separated from the extraction setup , and feed the action object as the input to wait for validation action activity.

By this we separate the extraction and Export setup. Every time a action is created, that will be added to the list and next document will be picked for extraction. once all the files are extracted then the control will move to the wait for validation loop created earlier and all the extraction result will be exported.

Hope I have understood the query right and this helps

Best Regards.

1 Like