What are all the issues we might face when we use modularity logic using invoke activity

As we doesn’t want to reiterate the same piece of code for different functionality - we are approaching modularity concept in a way we create the one function called main1.xaml which has a scope in Main 2.xaml.
In such a case we are following Invoke file activity .

Wondering what might be an issue in such case.

Also suggest me if any other easy way to call the function in other program.


Hi @kavinnatarajan

It is actually the best practice to create workflow files for actions that you do often, and then to invoke those workflows using Invoke Workflow File activity.

Could you let us know what types of issues you had in mind? It is the way to go in situations like you described and was designed to work really nice this way. You can pass arguments in and out of the invoked workflow files too, of course.

Moreover, since the 2018.3 release, you can create a Library project that will allow you to create a workflow that can be exported directly as a custom activity, giving you even more freedom to reuse your custom workflows :slight_smile:

1 Like