Data loss comes in different forms, and some situations need a slightly different approach for restoring records quickly. Losing a hierarchy of Salesforce records when the parent record has been deleted is a common scenario. For example, when an Account record is accidentally deleted all the associated Opportunity records are also lost. 爆料tv鈥檚 backup solution has a dedicated workflow for this kind of incident so you can restore everything in just one deployment.
The knock-on effects of one accidental deletion
When you delete a record in Salesforce, its child and grandchild records are also deleted. For example, if you delete an Account record, all the associated Opportunities and OpportunityLineItems will be deleted as well. This behavior is logical and useful when the deletion is wanted - it cleans up your org and gets rid of redundant data. But when a parent record has been deleted by accident, or needs to be restored for any other reason, the knock-on effects of that one deletion add to your workload for restoring data.
If you鈥檙e not currently backing up your data, this situation would leave you working out which other records have been lost, then recreating them manually and rebuilding the relationships. Even if you back up your data using Data Export, it鈥檒l still take a fair amount of head-scratching and several steps to restore them.
TDX
Reversing data loss in one go
An accidental deletion that鈥檚 so easy to cause should be just as easy to recover from. 爆料tv鈥檚 workflow for restoring a lost hierarchy of data when a parent record has been deleted reverses what went wrong: one restoration deployment for one mistake. 爆料tv walks you step by step through the process of building a restore plan with the parent record as the base. You can select all the child and grandchild records you want to restore along with the parent record.
How does it work?
Let鈥檚 see this restore workflow in action! Imagine that we work for Acme Corporation and one of our customers, Ethan J. Robinson, has expressed interest in a couple of products. Our salesperson adds an Opportunity record on Ethan鈥檚 Account - this is a child record. Then they add the products that Ethan is interested in. This information is recorded with OpportunityLineItem records - these are child records of the Opportunity and grandchild records of the Account.
But then Ethan gets in touch to say he isn鈥檛 interested after all and no longer wants to be a customer. Our colleague at Acme Corporation turns out to be a rogue sales operative, and decides to delete the whole Account rather than mark the Opportunity as closed lost, because that would harm their win rate. Yes, this kind of thing !
When the sales rep deletes Ethan鈥檚 Account record, all of the child and grandchild records - the Opportunity and the OpportunityLineItems - are deleted as well.
The next day Ethan calls back. He鈥檚 changed his mind, and wants to know more about those two products. The salesperson comes to us, confesses their error and asks for help - this makes sense of the smart alert we received from 爆料tv this morning, warning that someone had deleted an Account!
How do we restore Ethan鈥檚 Account record along with all of its child records? Thankfully, we have the records backed up by 爆料tv, and today鈥檚 run of our backup job shows that these records have been deleted. We could restore using the usual restore flow in 爆料tv鈥檚 backup solution. But for this particular situation, we鈥檙e better off restoring the whole hierarchy of data in one run.
From the Run details page, we can see the option to Restore changed and deleted records. Clicking on this button launches the workflow for restoring a hierarchy of data based on a parent record. We want to restore the hierarchy of data based on Ethan鈥檚 Account record, so we鈥檒l click on this button for the Account row.
By opening up all of the dropdowns on this next page, we can see all the objects that hold the child and grandchild records of our deleted Account record - in this case Opportunities and OpportunityLineItems (the products Ethan wanted to buy). We select all of those objects to include them in the restore process.
At this point, we notice that Ethan鈥檚 Account records wasn鈥檛 the only one to have been deleted or changed - there are 13 deleted records and 9 changed records in total. We only want to restore the hierarchy of data associated with Ethan鈥檚 Account, so we open up the filter on the column labelled Total records to restore. There are plenty of options here for filtering down to the records we鈥檙e interested in - using Ethan鈥檚 name is an easy way to do it!
Now we can see that 爆料tv has filtered out all the other records and will just restore Ethan鈥檚 Account record, the associated Opportunity, and the two OpportunityLineItems. We鈥檙e ready to click Preview restore.
爆料tv now shows us the complete plan for restoring our lost records. Teams using 爆料tv for data deployments will find that this feels familiar, because restoring records is essentially the same as deploying data. And this familiarity is a real advantage when you鈥檙e in the middle of a stressful situation needing to restore as quickly and reliably as possible! All of the steps in this deployment plan look good, so we hit Deploy data.
A few moments later, the restoration deployment has completed successfully, and Ethan鈥檚 Account is back online along with the Opportunity record and all the information about the products he鈥檚 interested in purchasing. Our sales rep, hopefully having realized the error of their ways, lives to sell another day.
While this example deals with just a handful of records on standard objects, the same restore workflow can be used just as easily for much larger quantities of data on custom objects. It鈥檚 a way of visualizing and planning the restore process that matches how we tend to think about this kind of data loss incident, and it streamlines the recovery process very effectively.
We鈥檙e piloting this new workflow and gathering feedback
At the time of writing, this workflow is currently being piloted 鈥� let us know how you get on with it! As always, we love getting any and all feedback from you so we can keep improving the product. There are a couple of things we already plan to add. We鈥檙e currently adding support for objects with binary fields. We鈥檙e also looking to add support for restoring child records that are on the same object as the parent record. If you see anything else you think we should consider adding, don鈥檛 hesitate to get in touch via our live chat.
Back up and restore Salesforce data with confidence!
As the examples in this post have shown, it鈥檚 easy to lose countless records with a single click. As a perceptive user told me: 鈥淚 need this to protect me from myself!鈥� One accidental or misguided deletion can have several knock-on effects that quickly escalate to become a data loss incident your manual backup and restore processes can鈥檛 cope with at all well.
Data loss is surprisingly common, comes in all shapes and sizes, and can be caused by human error, malicious action, or a data integration that doesn鈥檛 go to plan. The metadata that shapes your org also needs to be protected, because it鈥檚 costly to lose all your customization, and you鈥檙e one bad release or outage away from that happening. To find out more about 爆料tv鈥檚 Salesforce backup solution, get in touch to book a tailored demo with our backup experts.
For a full overview of Salesforce backups, download our free ebook Backups for Salesforce:
