How to Dynamically Invoke Workflows in UiPath Without Using If/Switch?

Help Studio
, , , , ,
1

Hi all,

I’m working on a UiPath automation where the robot needs to run different workflows based on the type of scenario — like “Approve”, “Reject”, or “AutoProcess”.

I want to avoid using multiple if or Switch statements to keep things clean and easier to maintain.
What I need:

  • The unattended robot should log in, do some tasks in an application, and log out.
  • Based on a scenario name (from config or input), it should call the correct workflow.
  • I’d like to manage this using a dictionary, config file, or naming pattern — something flexible without hardcoding each condition.
    My Questions:
  1. What’s the best way to do this kind of dynamic workflow call?
  2. Can unattended robots handle this approach reliably?
  3. Any tips, best practices, or sample designs would be really helpful.

Thanks in advance!

2

@logesh_kumar1

I believe system package should be >23.10 for using variables in workflows

Alternately one thing you need to bear in mind are the arguments and make sure they are dynamically mapped or use same argument names across so that only workflow name variables can be handled and the job is done

unattended robot can handle

cheers

3

@logesh_kumar1,

Even you store the scenario and workflow mapping in the config or dictionary, you will require to use if, switch or other control statement to direct the execution flow to correct workflow.

Here is how you can do it using json

workflowDict json

{
  "Approve": "Workflows/Approve.xaml",
  "Reject": "Workflows/Reject.xaml",
  "AutoProcess": "Workflows/AutoProcess.xaml"
}

Code logic:

If workflowDict.ContainsKey(scenarioName)
    Invoke Workflow File: workflowDict(scenarioName)
Else
    Log Message: "Unknown scenario: " + scenarioName
4

Hey @logesh_kumar1

  1. What’s the best way to do this kind of dynamic workflow call?

Use Process Arguments - it can easily be changed while running from orchestrator or scheduling a trigger. (We have a similar use case, where we use the same workflow for different location code with different arguments set in trigger)

  1. Can unattended robots handle this approach reliably? -
    Yes.

In your case, it seems like you are using same application, and even if the processing screens ae also same, except 1-2 steps → you can use flowchart with the process workflow of Re- framework- and use Flow decision to keep the workflow clean and understandable

but if the steps\ screen involved are mostly different, it is better to have three different processes for each of these “Approve”, “Reject”, or “AutoProcess”.

  1. Any tips, best practices, or sample designs would be really helpful.
    Use Dispatcher (add to Queue with Type attribute) and Performer (Process specific step)
    It would be easy to scale if volume increases.