Global Workflow v Multiple Global Workflows, performance and overhead question

As I build more complexity into my app, I’m wondering if there are any performance, security, maintainability, practicality, etc. considerations people have when considering breaking a single, large workflow into pieces.

For example, I have a large global workflow that does a bunch of different checks, via true/false splits, before allowing the action to complete. I’ve added functionality to it and had to refactor some of the true/false branches with updated logic…some of which have become fairly chunky in and of themselves.

Which has made me think maybe I should be splitting some (or each) of these T/F branches into their own global workflow, which are then called by the ‘parent’ workflow. In the below I started to do this (but haven’t finished) with the left side, “Is there a Schedule Exception?”

Is that a good idea, bad idea, or just personal preference?

It sort of makes intuitive sense to split it up, as then each step/branch can essentially become a ‘module’ I can reuse in other workflows. But I don’t really have a ton of workflows currently…so it’s not like I NEED this ability.

Are there any negatives to this (i.e., does calling a workflow inside another workflow add any sort of significant overhead)?

This post touched on this, but was more about concurrency. In my case this is not really a concern, as I don’t need to run the parent workflow multiple times.

Thanks

Hi Daniel :waving_hand:

Splitting your workflow into smaller ones would be better to improve your own readability, and be able to come back to them in the future and understand exactly what each part does.

Another thing is like you mentioned, the fact that you can turn those workflows into a reusable module.

And the final reason would be to improve your debugging process.

But you are not wrong in using a single one, is just a matter of preference.

1 Like