I am updating and inserting some records in salesforce, through a SOAP API service.

The procedure, corresponds to a simple update or insert to the fields of an Account record. It is required to handle the use case, where a Business Account(record type), changes into a Person Account(the standard record type, that gets activated, by salesforce, on your demand), or vice versa.

Due to the special nature of Person Accounts RT, I have designed the class, so it first sets the record type(FIRST DML OP), and then I commit in the database the other info of account records, in a second moment(i.e. Phone, email etc.)(SECOND DML OP).

Before commiting the second DML OP, i perform some data validation, according to the data received from the SOAP Request.

What I need, is a logic, that rolls back, the records modified in the FIRST DML OP, if they fail the custom validation, that I have specified, before the SECOND DML OP.

I've thought about using Database.SavePoint() & Database.Rollback(), but that rolls back all the records validated successfully. I want only to roll back, the update of the record type, for the records not validated.


Q: Why do I set the record type, separately, in a first DML operation?

A: Because, if you want to change the record type, from a person account, to another record type, or vice versa, you have to do it separately. Than you modify the fields, accordingly, to your business logic. This is workaround is also the only way suggested by Salesforce.

  • I did this once using a custom rollback method that did a manual DML delete of the records that failed the validation at step 2 while allowing the records that passed step2 validation to proceed to the update DML. You have to make sure you wrap everything in try-catches so no exception goes uncaught. A wrapper class on the incoming Accounts is helpful so you can easily mark the list of wrapped accounts as to which ones passed/failed the validation – cropredy Nov 11 '15 at 6:58
  • of course - one could ask why you can't do the validation before the first dml op if the data exists in the soap request – cropredy Nov 11 '15 at 6:59
  • Actually I figured out a cleaner way, inlcuding triggers in the show. Something like: - If RT gets changed in the FIRST DML. => Remember the old RT. - So if a record fails my custom validation(this is defined by my business logic), retrieve the old record type, and perform a "rollback" update of the record type. *The problem is that I am struggling to detect a Record type change on the account, when I am going from Business Account <-> Person Account. **It's strange because I am able to detect a change from Another Type of Account <-> Business Account, but not the first one. – Endrit Sino Nov 11 '15 at 15:57
  • 1
    your solution is essentially what I suggested except you retain the row rather than deleting it - if that is what your business logic says to do, works for me! – cropredy Nov 11 '15 at 17:37

Your Answer

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

Browse other questions tagged or ask your own question.