Limit amount of leads that run at the same time on a batch campaign

[Tamir_Belzer_TB]

HI, We have a batch campaign that is triggering Slack alerts but I was told that Slack cannot process more than 150 requests at the same time and probably even less. We have a batch campaign that updates the webinar status for attendees of webinars but for some webinars we have over 300 attendees and it updates them all at the same time. I was wondering if anyone has a way to run these group of leads in batches of 30-50 people with a wait step of 30 seconds between one another. 

I tried to use a random sample and static lists and a smart campaign that runs for every static list with a delay between them but it ran all of them at the same time. 

Any idea? 

[jsiebert]

@Tamir_Belzer_TB Could you use multiple separate batch campaigns that you schedule using the random sampling lists as your smart list criteria? This way you can control how many leads are being updated at a time. It's probably not as quick as you'd like, but that's the only option I can think of at the moment. 

[SanfordWhiteman]

---

I tried to use a random sample and static lists and a smart campaign that runs for every static list with a delay between them but it ran all of them at the same time. 

---

Not sure what you mean here. If you run campaigns at different times with different audiences (i.e. different lists), they... run at different times.  They won’t magically run at the same time. Of course if you don’t give enough time between the campaigns, there will still be overlap, and managing those intervals can be tricky because there’s no signal that all flow steps in a campaign are done. Only checking the Results tab can give you that info.

The overall answer to your question is that Marketo has no way to serialize outbound requests made from the same campaign. They’ll be parallelized up to Marketo’s outbound concurrent connection limit, which is fine most of the time because things finish faster, but some of the time — like here — you but up against limits on the remote end.

What we’ve done in such cases is send requests to a queue rather than directly to the remote service. Then pluck N requests off the queue at time, which could be as few as 1 at a time = complete serialization.