Hi everyone.
Hope your year is off to a great start!
Today, I want to explore the use of sequential vs. parallel processing in Make scenarios. Let’s consider a common example: sending webinar registration data through Make to register the client in Zoom, update your CRM, and add them to a Google Sheet.
With sequential processing enabled, each new webhook will be processed one at a time. John’s registration would proceed through Zoom, CRM, and Google Sheet before Johanna’s processing even begins. This ensures data integrity and avoids potentially conflicting actions for the same client.
However, disabling sequential processing can speed things up. While John is added to Zoom, the scenario could simultaneously start registering Johanna. This might seem efficient, but potential downsides exist:
Data conflicts: Two registrations might overlap in Zoom or the CRM, leading to errors or missing information.
Order dependence: If certain tasks rely on data from previous ones (e.g., CRM update requires Zoom ID), asynchronous processing could cause errors.
I understand that Sequential processing prioritizes data integrity and avoids conflicts, while parallel processing can be faster.
So when will I use the fast and less strict on data integrity?
I think that the default is parallel processing - right? isn’t it dangerous?
You’ve mostly answered your own question – use sequential processing when the IDs or order of incoming data is crucial.
If your scenario is more of the fire-and-forget stuff, like sending off an email auto-responder to the sender, then it makes sense to use parallel processing.
Hi @samliew
So as far as I understand the more safe and common way is With sequential processing enabled - right? so why this is not the default in make.com?
When an instant webhook is triggered, Make will process and execute the scenario as soon as the data is received. Let’s think of this in an example scenario that needs a response instantly, as it will be accessed by many users at once. You want to give your users their response as soon as they engage with your webhook, rather than have to wait.
There is no right or wrong way to process your webhook-enabled scenarios, it all comes down to what your preference are in the service that you provide.
To summarize:
Parallel processing allows for better responsiveness to webhook requests.
Sequential processing ensures Make waits until the previous scenario execution is complete before starting the next one.
Keep in mind that after making changes, your App API may need a few seconds to update with the new data. Therefore, even if you’re using “Sequential processing,” it’s essential to incorporate a Sleep module in your workflow to pause briefly, ensuring the App has already updated with the latest data.