Restore your data if someone accidentally deletes 1000 accounts from Dynamics 365

How do you restore your data if someone accidentally deletes 1000 accounts from Dynamics 365?

In the on-premise world, grab last night’s backup, restore it to another database, export the records and re-import.

However, that’s not as easy to do if you don’t have access to the back end.

The Basics of Backup and Restore

With the Dynamics CRM Update 1 release last summer, Microsoft added a feature to back-up your CRM Online databases every night.  

The backup works across each of the instances you are managing and it allows you to restore the backup as well.  This is a great feature addition and is well documented in this blog: https://blogs.msdn.microsoft.com/crm/2016/08/23/backup-and-restore-your-crm-online-instance/ and this TechNet article: https://technet.microsoft.com/library/mt748060.aspx

Option 1: Don’t Let Someone Accidentally Delete a Bunch of Records

The best way to avoid this situation is not to let it happen in the first place.

When you’re setting up security for your CRM modules, limit the “Delete” permissions (especially on core records like Accounts) to your System Administrator.

You can still keep your data clean by leveraging the Deactivate function on various entities and that is controlled by Write permissions, so they don’t have to have the Delete permission to Deactivate.

If you accidentally Deactivate 1000 records, then that’s an easy fix – just highlight all the records and reactivate.

In the out of the box security roles, all of them have some form of Delete permissions on Accounts (some are just User permissions, meaning they can only delete records they own). I I would argue that even Delete permissions on your own records is dangerous and I’recommend pulling that permission from all those standard roles and leaving users with the Write permissions so they can deactivate accounts but not delete.

There are many occasions where you create a dummy account in CRM and want to delete it, but let the user deactivate it and when there are too many of these, tell the sysadmin and have him/her delete those accounts.

To help protect you, CRM flashes this warning before you delete an account:

Don’t delete your account

Cascading Delete Settings

To prevent utter chaos when you allow users to delete accounts , restrict the “cascading delete” settings at the relationship level.

When you create a relationship between two entities, you can choose a “Parental” relationship (like Accounts and Contacts) or Configurable Cascading where you can choose what happens when a record is deleted.  

With custom entities  set “Restrict Delete” on the relationship with Accounts – to prevent you from being able to delete an account due to the existence of that relationship.

Summary - , please make sure you’ve modified  security to prevent accidental deletion as much as you can.

Option 2: I Didn’t Listen and Someone Blew Away 1000 Accounts, What Do I Do Now?

Rather than investing time in saying “I told you not to give them permissions to do that,” figure out what got blown away.

Generally, the perpetrator knows what they did, so ask them specifically which accounts need to come back.  If they don’t know which accounts are gone, you have to go through the steps to restore the instance to figure it out. Let’s assume we don’t know what records were deleted.

Retrieve the Backup

Typically , the standard backup occurs every 24 hours. If you were really cautious, you might taken a user-driven backup right before the user blew 1000 records with everyone else out of the system, so you could just restore that backup. That is highly unlikely, so I’m going to assume that didn’t happen. Let’s keep going assuming this was an unexpected deletion.

When you restore a backup of production, you can’t restore it directly to production – that’s a good thing.

 You will need to restore the backup into one of your sandbox instances. If you don’t have a sandbox instance, view this TechNet article, it explains how to get one.

If you need your current sandbox preserved, then you’ll need to do a user-driven backup of it and restore it.

Restore your production backup over your sandbox instance and now you’ve got your data back; however, it’s not in the right instance.

Figure Out What Needs to Be Restored

If you don’t know what was deleted, then your first step is to figure out what you need to bring back.

This can be  a big problem when you delete accounts depending on your “cascading delete” settings. When you have it set up to delete child records when an account is deleted, you also lost contacts, opportunities, activities, cases and who knows what else.

We may have 90+ entities that have a 1:N relationship with accounts, so the impact can be huge.

For simplicity sake, let’s say you lost Accounts and Contacts.

Open your account list in production and export everything out to Excel, then do the same thing in your sandbox. Dump your contacts out the same way.

If you can figure out what’s missing in Excel, that’s great. Otherwise, I to put the records in a SQL or Access database to compare the tables with a query that shows you what records are duplicated

(Once you get the data back that you need, put the records you want back into CRM into an Excel worksheet, save it as a CSV and import the accounts and contacts back into your production system. You would import the accounts first so the system will find the relationship when you import the contacts.

, if you deleted more child records, then you have to import all of those records as well.

The backup and restore features give CRM administrators the ability to restore records in the case of an accidental deletion of records. Let’s hope you don’t need to use it.