08-15-2023 10:47 AM
Can anyone tell me with certainty whether the losing records in a dedupe merge are soft or hard deleted? If the answer is, "it depends," can you please identify the dependencies? Thank you!
Solved! Go to Solution.
08-16-2023 08:34 AM
Hi @JGibbKillmer ,
My pleasure! Yes, in Legacy DemandTools 2.91 you would get a warning before doing merges. DemandTools 5.x does not do this. DemandTools 5.x does allow for unmerging of records via the Run History area. With DemandTools 5.x, you do have a restore file (which the system uses to do the unmerge) on the local workstation. Legacy DemandTools 2.91 did not have this functionality.
Unfortunately, I do not have a list of reasons why Salesforce may not retain your losing records in the recycle bin, but it does sound like #2 is a possibility if your recycle bin is full or if you're deleting more records than can be retained within your recycle bin:
"Your Recycle Bin can contain 25 times your MB storage capacity as records. For example, an org with a storage allocation of 2,000MB (2GB) can have 50,000 records in the Recycle Bin: 25 x 2,000 = 50,000 records."
You can find the quote in this Salesforce Article. As far as a Dedupe workflow, I would always highly recommend breaking up the batches into smaller ones the first time you're running it. I usually recommend "Last name starts with" or "Account Name starts with" and you enter a few letters delimited with commas. This way the batches are smaller and more managable. Once you're in maintenance mode, and even scheduling some of your Dedupe scenarios, you wouldn't have to worry as much about breaking them into smaller batches.
Hope this helps!
08-15-2023 01:13 PM - edited 08-15-2023 01:13 PM
Hi @JGibbKillmer ,
There is only one setting that would change this behavior in DemandTools 5.x. I don't think there's any settings in Salesforce that would turn off the Recycle Bin, correct?
As long as you don't have the "Merge Option" of "Add Prefix" turned on, the losing records will be soft deleted into your Salesforce Recycle Bin.
Regards,
08-16-2023 06:46 AM
Thanks, Anthony! My colleagues and I had a couple other possible caveats in our heads around soft/hard delete.
1) When merging, in old DemandTools I could swear there was a disclaimer about restoring before running the merge. Am I remembering that right? That's what prompted my question.
2) Isn't there also a situation in which you might be using the API (bulk or not) to do deletions, and you get a warning of the possibility that not all records will be restorable?
08-16-2023 08:34 AM
Hi @JGibbKillmer ,
My pleasure! Yes, in Legacy DemandTools 2.91 you would get a warning before doing merges. DemandTools 5.x does not do this. DemandTools 5.x does allow for unmerging of records via the Run History area. With DemandTools 5.x, you do have a restore file (which the system uses to do the unmerge) on the local workstation. Legacy DemandTools 2.91 did not have this functionality.
Unfortunately, I do not have a list of reasons why Salesforce may not retain your losing records in the recycle bin, but it does sound like #2 is a possibility if your recycle bin is full or if you're deleting more records than can be retained within your recycle bin:
"Your Recycle Bin can contain 25 times your MB storage capacity as records. For example, an org with a storage allocation of 2,000MB (2GB) can have 50,000 records in the Recycle Bin: 25 x 2,000 = 50,000 records."
You can find the quote in this Salesforce Article. As far as a Dedupe workflow, I would always highly recommend breaking up the batches into smaller ones the first time you're running it. I usually recommend "Last name starts with" or "Account Name starts with" and you enter a few letters delimited with commas. This way the batches are smaller and more managable. Once you're in maintenance mode, and even scheduling some of your Dedupe scenarios, you wouldn't have to worry as much about breaking them into smaller batches.
Hope this helps!
Get industry news, expert insights, strategies, and hot tips, served up fresh every week.
Visit the Validity blog