Asynchronous Workflows

[joeworkman]

I have an interesting idea that I hope I can properly convey. ActivePieces, like pretty much all similar automation tools, processes a workflow in a very linear fashion.

This make sense if Step 2 was dependent on Step 1 and Step 3 was dependent on Step 2. However, in my experience, this is not how most automations work.

What if the steps happened more asynchronously?

In this example, my trigger could trigger multiple actions at the same time. You only need to nest a step if it relies on a previous step in some way.

I feel that something like this could really set ActivePieces apart from all other competing products.

I hope I properly conveyed my idea here. Let me know if I can provide any further clarity.

[ashrafsam]

@joeworkman Your proposal is interesting. I’m more familiar with the idea of “multiple triggers” where you can add Trigger 1, Trigger 2, Trigger 3 then all of them lead to executing the same consequent steps.

Now when it’s 1 Trigger and multi paths, do you have a real life scenario where this could help?

Also, a simple workaround for this is to add the trigger then send 3 HTTP requests to 3 async URLs (other flows that start with Webhooks on Activepieces for example) which allows you to run the 3 flows in parallel, all triggered by 1 Trigger.

[joeworkman]

Here is a workflow that I will be moving off Zapier and onto AP soon.

• Steps 1-3 must run. Although I will eliminate step 3 and guarantee a result in Step 2.
• Step 6 requires Step 5.
• The rest of the actions only rely on data from Step 2. Therefore, steps 4 on could be ran asynchronously.

Another benefit of running async is that a failure in one step will not stop the execution of the other steps below it since they will not be dependent.

[Ravi_Mittal]

I too felt it. While a linear approach offers simplicity, it can be quite restrictive. Similar to algorithm functions, we should have the flexibility to incorporate conditions like “if” and others for a more dynamic approach.

[joeworkman]

@ashrafsam I was wondering your thoughts on this? Think the idea has any legs?

Another potential implementation of this idea could be that if you want a step to be asynchronous, then that step should be a separate workflow. That separate workflow could then have whatever steps you want.

[Davide]

The idea of asynchronous flows makes so much sense… I use different automation platforms, the ones that allow asynchronous flows are 100% on top of my list.
I think it would be a great feature to add to your automation builder.

[KenHROI]

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.