If you're looking for a jump to sort of functionality, you might consider tickets, but you'll want to be careful. What I might suggest is a master flow which calls all of your subflows, that way when you wan to go back, you just need to hit an end shape and pass a value for which flow you want to route to next (you'll need to account for really being done, but arguably "end" could be passed in to say unwind the main flow completely).
Thanks for your inputs Mike.. Based on your suggestion, I've tried something similar, using Screen flows: I have created a "master flow" as you said,which refers to a "sub (screen) flow" which in turn has 'sub-processes' each referring to my flows. But I have to convert my flows into 'screen flows' as the sub-process in a screen-flow didn't allow me to connect to my original flows (as they are not screen flows).
But doing this, my flows have a few routings to work baskets, which cannot be done in screen flows.... Any ideas on how can I route to a workbasket from a screen flow..?
I haven't tried doing that in quite some time. If you are trying to route a screen flow to different work baskets, it sounds like you are going outside of the scope of that functionality. Is this whole design something that might be better served using a tree navigation? It sounds like you want your users to be able to jump backwards and forwards as you collect data and that should allow you to do it.