How to input arguments when invoking a dynamically defined workflow file name

[louiemed (Louis)]

Hello, I am currently building an automation that looks at service tickets for users who have just been terminated from my organization and need to have their licenses deactivated within various software.

When the bot looks at a service ticket, it pulls the name of one application to check for the terminated employee. It then compares this Application Name in an else-if block against hard coded app names (see picture 1).

I am trying to update this functionality so whatever text is found on the ticket, is compared against a Dictionary of pre-defined app names. I have done this successfully and am able to invoke the proper workflows, but I realized that I cannot set the arguments because it does not know what workflow it is invoking until runtime. (see picture 2)

Has anyone had to deal with this issue before? Please see photos for details

[Anil_G (Anil Gorthi)]

@louiemed

Arguments can be sent as dictionary…you might need to define a dIctionary and add the argument data and required input argument names to it..then click plus beside arguments and select open advanced editor to pass the dictionary

Other way is to declare all arguments in all workflows this way arguments will remain same but few values might be missing but anyways there are not use so no harm in it

I would say approach 2 better as it avoids dynamic dictionary creating again based on condition

Cheers

[J0ska]

I have a scenario in which I use dynamic named workflows.
However all workflows share same list of arguments therefore no problem fill it.

You can also supply arguments as Dictionary variable

Cheers

[andrzej.kniola (Andrzej Knioła)]

Your original question was answered, but just as some unsolicited advice , speaking from experience (we’ve had projects like this in the past), whoever will be maintaining that 3/6/12+ months later (which could be the future you) will grow to hate this design with a passion.

Decoupling in traditional software is usually a good thing. Decoupling in UiPath xaml’s (or most visual scripting, really) is a royal pain. It doesn’t remove the dependency, it just hides it with an abstraction layer.

I’d highly recommend marrying the two concepts together:
Your classification to a dictionary is a good step (I’d personally go with an enum, but that’s just me). Now instead of the original if/else, do a switch and drag in those workflows and set the arguments, especially if they can vary.

It may seem like more work, but you gain static checks on mismatched arguments, and most importantly also it will automatically update on rename and path changes (which is very easy to miss in dynamic dispatch scenarios, and since you’re keen on refactoring it seems, that will be a thing sooner or later).

(I was going to say here that it also gives a compile time error on missing workflow invoke, but apparently that’s not a thing, which seems like an obvious oversight in the workflow analyzer - it should at least be a warning for any invoke with a relative path…).

Remember that code is read multiple times more than written, therefore the focus when writing code should be way more skewed to make it readable and easy to follow. You never know what will be the skill level of the next person working on the project, and while some base level has to be assumed, you don’t want to make it harder to understand what’s going on than it needs to be.

TL;DR: the original if/else design could be better, but it definitely has pro’s that the dynamic invoke does not have. Before doing any refactorings, always ask yourself “why would someone write something this way?”. The answer might surprise you.