Is it possible to create a shared queue across multiple Zaps?

Hi @MartinKjeldP!

It is possible for Zaps to share queues created by the Delay by Zapier action. To do that, use the same queue name for both queues in the two separate Zaps and the items will share one queue. 

Although this answers part of your question, I’m not sure if it addresses everything because it’s not possible to specify that all items from one Zap should be added to the queue before all of the items for another Zap. Will creating one queue for both Zaps work for what you need?

If you need some more help trying to figure out this one, could you share some more information about how/when each Zap triggers? Thanks!

@Danvers Thank you for the reply. I was unaware that it is possible to use the same queue just by using the same queue title across Zaps. I think perhaps this bit of information is lacking from the article about delays. This at least removes the Sub-Zap step that I had described in the above. I will have to test this and stress the Zap with many concurrent events. 

@Troy Tessalone Thank you for your reply, too. With regards to chaining Zaps together user webhooks: I am unsure how this would work. Our setup is something like this: 

1. Changes for customers in our CRM trigger a number of webhooks, depending on which CRM sub-system is edited. For instance, one webhook is triggered on customer field changes, whereas another webhook is triggered if the customer’s account access/plans are created/edited.
2. A number of Zaps catch the webhooks. Their immediate next step is to continue to the shared queue (right now, this is set up using a Delay After Queue step in Sub-Zap, which all of the Zaps call). 
3. When each event passes through the queue, the Sub-Zap returns an event to the respective originating Zap, which then continues with its sequence of steps. 
4. Depending on the state in both our back-end and our CRM, the Zaps branch out using Paths to create/POST or update/PUT users and accounts in our back-end. This is where issues with race conditions may arise, i.e., if several webhooks are triggered from our CRM at the same time and attempt to create/POST a new user/account in our back-end. 
   1. It should be noted that when the Zap POSTs to our back-end, it retrieves an account/user ID, which is then updated for the respective account/contact in our CRM. The Zap branches to POST and PUT paths depending on whether this ID is set in our CRM. 

In this event, although it may be difficult to assess given the details provided, how would we be able to ensure that they process in the desired order?

@MartinKjeldP 

Another concept might be to use an intermediary database such as Airtable.

• Airtable has Views
• Views have Filters (e.g. Field X = True AND Field Y = True)
• Views can be used to trigger Zaps
• Views can be used to trigger Airtable Automations
• Airtable Automations have Run Script actions (on Pro+ plans) that can be used to trigger a Zap webhook

So it’s possible to only have Zaps enter a View when conditions are met giving you more control over the flow.

@MartinKjeldP

For each Zap Run of Zap 1, if you want Zap 2 to process after Zap 1, then chaining Zap 1 to Zap 2 will ensure that Zap 2 only processes after Zap 1, thus creating a controlled order of operations.

Hello. I had posted a comment as a reply to @Troy Tessalone’s latest comment, which looks to still be in review with the community moderators. 

The input provided did not solve the issue of race conditions, as described in the mentioned comment that is under review.