I think the proposed solution was to incorporate the 'exclusive split' in the sub-microflow as well; then the sub-microflow starts with the split, and based on the split retrieves one of the 2 project lists, which in turn are returned in the end-events of the sub-microflow.
Then: this 'returned list' can be used in the parenting microflow
The easiest would be to simply create a microflow that returns the result of one of the 2 retrieve actions and then you would have the same variable name for the list in the calling microflow. It is not driectly possible with standard activities to do this differently other than building the resulting actions twice in the same flow using name1 or name2 lists.
Anothe roption could be to write a java action, but that would be sort of the same as the submicroflow.
Oops, maybe I’m missing something but moving the retrieve actions in two microflows still doesn’t work, no way to have to same list name.
Maybe the only solution (wasting time and resources) is to filter out the list after it has been retrieved.
I ended up with a Remove Object action.
Definitely, not the more effective solution from the database retrieval action point of view but it is the only solution that worked for me.
Any suggestion is appreciated.
It worked, thank you for clarifying it.