The general process seems simple: some critical data was lost due to several potential reasons (Salesforce infrastructure failure, internal mistake/miscommunication, etc.), and the data needs to be recovered to the state it was in before the incident as quickly as possible. Unfortunately, many of us realize that the process is not simple after it’s too late and the incident has already happened.
Manage Your Automation With CS:Restore
Apex triggers, validation rules, flows, restricted picklists, and even legacy workflow rules are crucial to consider as part of a Salesforce data recovery process. If you do not adequately manage automation features when restoring data with CS:Restore, you can easily experience undesirable effects. For example, one of your sales reps accidentally deleted an Opportunity. Upon inserting an account record, your Salesforce org has an apex trigger that will initiate notifications for Opportunities larger than $50,000. Therefore, you should disable this automation before recovering the lost data in a data recovery situation.
Another example: Say you have lost some historical data and need to recover it. Your validation rules have changed over time, and much of that historical data will not pass the current validation rules. In this scenario, you must disable these rules to recover the data correctly. But wait, what if you have tons and tons of automation, and it would take way too long to disable and re-enable it all manually? What if you aren’t aware of all the relevant automation, and it would take too long to dig into your Salesforce data model to discover it all? Or, what if you forget to keep a list of which rules need to be turned on again after the completion of the restore?
In comes CS:Restore to the rescue! CS:Restore has built-in functionality to manage your automation when recovering data automatically. It will automatically discover all relevant automation when restoring a record, disable it before pushing the record, and then promptly re-enable it. This can all be done by simply checking the “Enable Automatic Management” checkbox within the application’s “Advanced” tab. In addition, there is a checkbox for each of the various Salesforce automation features to manage them individually.
Special Permissions Offer Peace of Mind for Your Data Recovery
What if some of the automation related to the relevant restore set is crucial to my business processes? What if I can’t afford to disable them, even temporarily? No problem, we can do better with some planning and proactive design! When architecting your Salesforce automation for Salesforce data recovery, it is recommended that you also create a special permission set that can bypass all automation. This will require a bit of work as you need to modify all automation to ignore actions taken by a user with this particular permission set, but it’s worth the effort! Once you’ve done this, you must assign the permission set to the Salesforce user you provide to CS:Restore, and voila! Now, you do not even have to think about automation in a data recovery situation. You can safely proceed with recovery without worrying about triggering an accidental email blast or having to hunt down restricted picklist issues.
Proper Planning Can Streamline Recovery
We understand how stressful a Salesforce data recovery situation can be. Depending on how critical this lost data is for your business or how much time has passed since you detected the loss event, the acceptable timeline for resolution can vary wildly. However, more work done ahead of time and proactively creating a Salesforce disaster recovery plan to make your recovery process as straightforward as possible means less stress on the inevitable judgment day when data is lost or corrupted. Not to mention how happy your boss will be when you have very quickly put out that production fire on a Friday afternoon!
If you are interested in speaking with one of CapStorm’s experts, click here to submit an inquiry or here to book a demo of this technology.
FAQs
- How do I bypass an Apex trigger with a custom permission?
- You will need to implement some logic within the Apex trigger execution code that will check against the custom permission and fail early if it is present. You may find the checkPermission method of the FeatureManagement class helpful.
- How do I bypass a Salesforce Flow with a custom permission?
- Essentially, you will need to modify the start element entry condition formula of your flow to have the following line:
- NOT ( {!$Permission.} )
- You may find this article helpful as well.
- Where can I learn more about automatic Salesforce automation management within CS:Restore?
- Here is a link to our LEARN documentation center for more information about automation management with CS:Restore: