Find your content:

Search form

You are here

What are your options if you start to run in to @future method invocation limits?

 
Share

Salesforce limits all account types to 200 future method invocations per full paid license every 24 hours. Are there any known options to increase this limit? If you start to run in to this is your only real option to find a new approach or buy more licenses (just for the limit increase)?

Does SFDC let you buy higher limits or provide any other way for orgs to be able to bypass this limitation?

Edit: I've been asked for more details, but really I'm really just trying to get this question answered - often people will try to give alternate solutions to whatever example you throw out. There are a myriad of reasons or scenarios where future calls might be the best solution but there is a risk of running over the limits.

For the sake of an example though, how about this: You need to make a callout in a trigger which then necessitates a future call. You have a relatively small number of actual accounts (say, 50) and a much larger number of partner accounts (which don't add to the limit, let's say, 1,000). The partner accounts fire the trigger and make the callout but now we are looking at about 10 futures per partner account per 24 hours, which may not be enough.

Another example: You have multiple managed packages installed that all make some number of future calls and you start to go over your limit.

Really, the why in this case isn't that important, I'm just wondering what, if any, the options are.


Attribution to: Ryan Elkins

Possible Suggestion/Solution #1

What are you trying to do? More info would help. IME it's pretty unusual to run into the 200 futures/day limit although I can see that it would be more likely in a small userbase. Haven't heard of this getting blacktabbed, but I've never heard of someone needing it to be. It never hurts to ask, although as with anything like this it will likely be hard to get approved and will be helped by a good relationship with your salesperson. Options for a workaround could be some combination of:

  • directly reducing future method invocations (sounds obvious but I have had a client who was making dozens of unneeded future calls per user per day)
  • batching (either via Apex scheduler, Apex batches, or more functional batching)
  • API integration (instead of a future call, make an external WS call to somewhere that knows what to do via API)

More info on your exact problem would help though.


Attribution to: jkraybill

Possible Suggestion/Solution #2

Are you using @Future inside a Trigger? Per the above comment, if you can put that logic into scheduled apex batch classes it will make your life much easier.


Attribution to: CoryCowgill

Possible Suggestion/Solution #3

According to the documentation this is a hard limit, though perhaps there's hope in what ca-peterson mentioned about his discussion with people in the partner program. But assuming for now that you're hard-limited, here's the direction I have gone numerous times.

Instead of making callouts from @future methods in triggers, which has other negative consequences around being fired from another future method or from a batch Apex method (it's forbidden), make your callouts from batch Apex.

The current limit is 10 callouts per execute method, but even making a single callout per execute is a huge benefit. Have your trigger insert records to process into a queue rather than going straight to future methods. Then, once per hour, a scheduled Apex process wakes up and processes items in your queue - or have your trigger launch the batch apex after it's done appending to your queue. Make sure your executeBatch call processes only 1 row to allow only 1 callout per execute pass, like this:

BatchApexClass bac = new BatchApexClass();
Database.executeBatch(bac, 1);

With this design pattern, you could literally have millions of callouts queued for processing and they will definitely get processed over time, at the rate of 1-10 callouts per row returned in your batch Apex class's query.


Attribution to: Adam
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/407

My Block Status

My Block Content