I am having a small doubt, and want to have some inputs on that.

For future methods, we are not allowed to have sObjects as method params/arguments. and the reason in documentation is stated as below:

The reason why sObjects can’t be passed as arguments to future methods is because the sObject might change between the time you call the method and the time it executes.

However, we are having same feature in queueable. So does that guarantees data integrity?

If yes, how that ensures data is not overridden.

If no, why it is not extended with future only(instead of new framework).

Thanks in advance!


Queueable is a completely different framework from future methods, and it gives a lot of benefits over it. It was probably easier and safer for salesforce to create a new framework/interface, than the modify the existing @future implementation without breaking existing apex code.

Also, it's likely that the reason why future methods can't take sobjects was true at the time of writing the documentation, but obviously no longer accurate as another framework (queueable) is able to handle sobjects.

Long story short, it's probably due to shortcomings of the @future framework + innacurate/outdated documentation.

|improve this answer|||||
  • but still with old logic, there is still possibility for object field overwrite. So that's the risk delegated to the end user? – Ysr Shk Oct 23 '19 at 11:26

To add to the already good answer - There's no documentation stating "why" there's no risk of data integrity within the queueable framework. However, I think it can be assumed (based on the info available and the fact that it's a different framework) that queueable is able to pull the sObject before it executes (as opposed to being limited to only using the instance of the object when it was actually passed) and eliminate any issue where the object might have changed by the time it's actually executing.


enter image description here

|improve this answer|||||
  • hmm.. I thought SFDC serializes the argument(s) passed to the Queueable's constructor and hence the value made available to the queueable object is the one known at time of System.enqueueJob(new MyQueueable(mySobject)) – cropredy Oct 24 '19 at 1:14
  • Thanks for the answer, this is closest to the answer.I will do one POC to check whether it pulls updated copy or old copy with conflict. – Ysr Shk Oct 24 '19 at 7:52
  • I'd be interested in your results @YsrShk – Kris Goncalves Nov 1 '19 at 13:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.