How to process Service Requests of different types in UiPath

I have a system which catches the Service Requests with the frequency of 3 tickets in 15 minutes.
I want to introduce RPA solution to process all 3 tickets by Robot but remember all 3 tickets may or may not demand same solution i.e. each ticket may be of different issue.

How to achieve this using UiPath?

Hi @gs1576 ,

there are a number of ways to achieve something like this in UiPath, depending on the exact scenario you wanted. Here are two examples:

  1. You only want the robot to process certain tickets -
    Use the ReFramework, dispatcher and queues. This solution would have you build two automations the first would be called a dispatcher and would go and get the tickets, it would look at the type of ticket it is, and if the ticket type relates to a ticket you want the robot to process, the dispatcher will add a queue item into orchestrator with something like the ticket number as a reference. it will go through the tickets like this creating Queue items for each ticket which is of relevance and ignore the others. Then you will have a second automation which would look at the queue items in orchestrator and process them one by one, therefore only processing those tickets which the dispatcher identified as relevant for this process.

  2. You want the robot to do something with each ticket, but this could be different things depending on the ticket type -
    You could achieve this using the same mechanisms as above, with a dispatcher which identified the type of each ticket and then created queue items in orchestrator across multiple queues so each ticket type was allocated to the correct queue (like a bucket of work) and then had different robots doing different processes picking from the relevant queue for that process.
    You could also achieve it all in one process where the robot picks up a ticket, looks at the ticket type and then performed a certain action based on the ticket type. if the ticket is a password rest ticket it would go ahead and do a password reset process, if it is a user setup ticket it would go ahead and do the user setup process, if it is a nothing ticket it will just close the ticket down etc. This option isnt as preferable however, because you will have quite a complex automation doing many different things, and also you will not benefit from the error handling and transactional logic which you get through the use of UiPath queues.

Its a little difficult to explain the whole scenarios in depth, if you want to provide more info on what exactly you want the robot to do we can probably elaborate further with a steer on how to produce it in UiPath.

Many thanks,

2 Likes

@Djh Many Thanks for your reply.

I can relate what you are trying to say with both well explained scenarios.

Only thing I need to understand, what should be the schedule duration for Dispatcher? and also, what should be the time allowed for Performer?

I am thinking of a scenario, suppose I have 5-6 queues which majorly deals with most frequent tickets( 1 queue is dedicated to 1 type of SRs here).

So now, Dispatcher will dispatch the SRs based on their nature to either of these 6 queues. Then how the performer will perform it’s job?

Should I create 6 different Robots, where each Robot will deal with 1 dedicated queue?

Is my understanding correct, or there could be an optimized solution possible?

Thanks

HI @gs1576, you can have one robot perform many different processes, which it will process sequentially depending on how the triggers are set up.

For the scenario you described, I would have the dispatcher being set off on a time trigger, so that it runs maybe each morning or multiples times during the day, and set the job to have a high priority.

Then set up the other 5/6 processes to run on the same robot but create their trigger to be based on queue items going into their respective queues, I would also set the queues to have unique references so you the dispatcher doesn’t accidentally put duplicates in there.

Depending on the volume of tickets this should work well, the dispatcher will take priority and then each of the other processes for the specific ticket types would be triggered only if there are items to process. If there are a large amount of tickets and the robot is struggling to keep up with all of the processes then you would then scale up the number of robots, maybe putting the highest priority or highest volume tickets being performed by an extra robot to manage the workload better.

Let me know how you get on

Hi @Djh

I completely understood what you are trying to say.

But I need to understand only 1 statement of yours - “the dispatcher will take priority and then each of the other processes for the specific ticket types would be triggered only if there are items to process”.

How the Processes will get to know if it’s dedicated queue is empty or not without triggering it?

When you set up a process trigger you can either set it up based on a time condition, like 9 am, or you can set it up based on a queue trigger. What will happen with a queue trigger is that Orchestrator will notice when a queue item goes into a certain queue which you have associated with the trigger, and then it will set of a command to start the job. if no items get put into that queue, the process wont be triggered at all.

yes makes sense.

Now i can picturize the complete solution.
Thanks to You @Djh

Cheers

Great, I’m glad that helped. If this solves the problem then please mark one of the responses as the solution and it will close down the open question for you.

Many thanks,

2 Likes

Just did that.

Thanks
@Djh