I'm running into an issue with too many future calls when handling Platform Events with a Process Builder that uses an invocable Apex class.

Basic setup is 2 processes: The first publishes an event on a custom object create (w/ a scheduled action to allow for the record to be committed before event subscriber gets the event)

The second pulls 2 fields from the Platform Event and passes them to an @Invocable Apex class, which in turns uses a @future method for async processing.

Everything works fine except for the fact that I appear to have no control over how many Platform Events are getting batched together on the way to the subscribing Process. I expected each Event would be executed in it's own context, however it clearly is not as I hit the "too many future calls limit" at 51. I've seen that this is in fact the case and that the "batch" size could be as large as 2000.

Is there any way to control that batch sizing so I can keep my @future call working? Or do I have to abandon ship on this whole architecture?

  • 2
    Queueable chaining is a good alternative to the one-future-method-per-record pattern that could allow you to keep the rest of your architecture intact.
    – David Reed
    Nov 13, 2018 at 16:24
  • 1
    There doesn't seem to be a capability of controlling batch size, so you may need to design/implement it differently.
    – Jayant Das
    Nov 13, 2018 at 16:28
  • 1
    According to trailhead triggers only execute on up to 200 records a time and you can also use a trigger instead of a PB as a listener for events. In the instance of even batches of 2000 records, that would translate to 10 triggers or 10 future calls, assuming your future calls are bulkified in their own right. The answer may be as simple as switching from a PB to a trigger. Otherwise, can you provide your @future code?
    – gNerb
    Nov 13, 2018 at 16:49
  • I'm going to see where I can get using a trigger on the Platform Event itself. Previously I had been trying to publish from the custom object Trigger. That was problematic because the Subscriber started working on the Event before the custom object record was commited (as is noted in the dev guide).
    – torpy
    Nov 13, 2018 at 18:34

1 Answer 1


In this instance I'm able to slice up Trigger.New Platform Events into manageable chunks that don't blow up the @future limit. Since the scale of my input is unlikely to grow large enough to break this model I'm happily chugging along. Publishing the Events with a Process does work well so I'll be keeping that part for now.

I'll definitely look into Queueable chaining for other purposes though, thanks for the reminder that exists David Reed!

I apologize for the rather broad question, and for answering it myself.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .