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.