Was there ever any internal discussion on this? Basically what they are requesting is the “router” piece from Make.com (just like this guy wants to do What's the Activepieces equivalent of a router in Make?).
The idea of using the flow itself as a router that pushes them into X additional flows via an HTTP request as you suggest in 2023 @ashrafsam is a good workaround.
However, that gets a lot more unwieldy and hard for people to follow vs just having it all in front of them and setting up the paths like you see in the Make.com example I linked to.
It also means that we will potentially have to use extra pieces meaning wasted tasks in some scenarios.
For example, if I want to push something into LeadConnector (HighLevel) via their API, I have to use a token which I have in storage.
If I need AP to perform 3 different tasks, then I would have to use the storage piece in each of the workflows vs just grabbing the token in the first step and then being able to reference it in each of the paths.
Imagine I’m building an RSS bot that is going to take a blog post and then create specific posts for Twitter, Facebook and Instagram.
I publish 6 articles per day, so just those 3 extra token retrieval pieces would equate to an extra 12 tasks per day (6 X 3 = 18 - 6 I would need if we had a router piece = 12) which means I’m using up 360 extra tasks per month just because.
Plus the extra HTTP requests and triggers.
Now imagine if that process requires additional redundant pieces along the way…
Or if I run the same process for several websites (which I will need to).
Over time I’m burning resources for no reason vs just using a “router” piece that can achieve the same task.
I think your asynchronous idea has its place, but so does the router piece which is why so many people are promoting Make automations on Youtube for similar use cases.
Yes, I know I can figure out a way to add it to the payload being pushed over to the 3 “sub-workflows,” but I want to give you an example of what less tech savvy users would likely encounter.