0

Is there a way to roll back the changes (data) if the record is rejected by the approver using standard approval process in salesforce? I've checked and it seems there is no OOB to do this. Is trigger the only way to roll back the record data in this case? For example: Contact record with email (abc@test.com) > Email modified (as def@test.com) > record sent for approval > approver "Rejects" it. Now i want the contact record with data (rolled back) as abc@test.com

  • on how many fields do you want to apply an approval process? Just Email? Or all Contact fields? – Guy Clairbois Oct 11 '16 at 12:07
  • @Guy I was about to ask him a same question, If there are less number of fields then Old value should be kept in separate fields and later can be used to update Original fields with Old values on Rejection action taken by Approver. – Devendra Oct 11 '16 at 12:11
  • In my case, its around 10-15 fields. From @Devendra 's comment, it seems its not gonna be OOB and a custom logic (oldMap) to be used. Correct me if am wrong. – Vignesh V Oct 11 '16 at 12:20
  • It would not be only OOB. It would be combination of both Customization and Configuration. – Devendra Oct 11 '16 at 12:24
  • Even a trigger won't work as the intitial change and the reject later on will be 2 separate transactions, thus during the reject, the oldMap will not contain the original values anymore. – Guy Clairbois Oct 11 '16 at 12:27
1

If you want to do a rollback of a large number of fields (or actually an entire object) you can't use workflow or triggers anymore but need to use APEX in combination with a datastore to store the old data that could be needed to roll back.

I'd suggest one of these solutions:

  1. create a full copy of the record and store it in another place, invisible for the end user. If you have an object with public readability, you might even need to create a separate custom object to store the data. Then add some APEX to create and cleanup the pseudo-object. Then have the APEX called by a trigger which in turn is triggered by an approval process.
  2. create a long text field on the object and use APEX to write a JSON string of the object into the text field. Then if the approval is rejected, use APEX to generate back the old record from the JSON string. The triggering happens the same way as for #1.

2 is easier more lightweight but you could run out of space in your long text field if there's a lot of data to save..

  • 1
    I'm glad I've never had to deal with this requirement. #1 would mean dual maintenance when new fields added and a clever rollback that exploited describe information. #2 is easier but to be generalized, might need to overflow into multiple 128K long text fields - though you still end up having to avoid processing formula fields and auto-number fields. What a mess. Better to avoid the problem in the first place via application design. – cropredy Oct 11 '16 at 16:35
  • fully agree with you @cropredy – Guy Clairbois Oct 11 '16 at 17:19
  • @Guy Thanks for the response. I also thought about the approach similar to option 1 which you suggested. Here, in my case, i dont think ive to go for another object. Instead i can have the duplicate fields (say, Formula fields and not visible to users) and populate the values there. Then, once the record gets rejected, will update a field (say, status as "Rejected") > Fires a after update trigger > Logic inside it to fetch values from duplicate fields and assign it to respective original fields. How about this? – Vignesh V Oct 11 '16 at 21:32
  • Yes that is an option as well if the amout of fields is reasonably limited. Probably not formula fields but fields of the same type as the original ones. Then you could even workflow (or even the approval process) to copy the values back and forth. None of the solutions is very elegant, though, as already stated by @cropredy. – Guy Clairbois Oct 12 '16 at 7:29
  • That's right! Maybe Salesforce has to do something about this. – Vignesh V Oct 12 '16 at 10:39

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.