stoneridgesoftware: How to Restore Inadvertently Deleted Accounts in Dynamics 365 (CRM modules)

[Blog bot]

Источник: https://stoneridgesoftware.com/how-t...5-crm-modules/
==============

How do you restore your data if someone accidentally deletes 1000 accounts from Dynamics 365? I was attending an event with a client at our local Microsoft office this week and this question came up. It stumped us for a few minutes, but once we figured out the answer, I thought it would be a great blog article so others don’t have to be confused in the future. This customer is used to on-premise software and has excellent DBAs, so in the on-premise world, they would just grab last night’s backup, restore it to another database, export the records and re-import them. However, that’s not as easy to do if you don’t have access to the back end. Before we get into the harder question, let’s start with the basics of Backup and Restore in Dynamics 365 (CRM modules).

The Basics of Backup and Restore

With the Dynamics CRM Update 1 release last summer, Microsoft added a feature to backup 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...line-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, that’s an easy fix – just highlight them all and reactivate them.

In my quick review of 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 would argue that even Delete permissions on your own records is dangerous and I’d recommend pulling that permission from all those standard roles and leaving them with the Write permissions so they can deactivate accounts but not delete them. There are many occasions where you create a dummy account in CRM and want to delete it, but let the user deactivate it and if there are too many of them, 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

One way you can prevent utter chaos if you allow users to delete accounts is to 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.  One thing you can do with custom entities is to set “Restrict Delete” on the relationship with Accounts – by doing so, it would prevent you from being able to delete an account due to the existence of that relationship.

Before we go to the next section, please make sure you’ve modified your 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,” let’s jump into how to solve the problem.  First, you need to figure out what got blown away. Generally, the perpetrator knows what they did, so ask them 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

As described in the backup and restore articles linked above, the standard backup occurs every 24 hours. If you were really cautious, you could’ve 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 unexpected.

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, you’ll need to do a user-driven backup of it and restore it after we finish this. Restore your production backup over your sandbox instance and now you’ve got your data back; however, it’s not in the right instance.

Figuring Out What Needs to Be Restored

If you don’t know what was deleted, your first step is to figure out what you need to bring back. This is a big problem when you delete accounts in particular, depending on your “cascading delete” settings. If you have it set up to delete child records when an account is deleted, you now lost contacts, opportunities, activities, cases and who knows what else. I noticed in our instance we have 92 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. The easiest way to figure out what you lost would be to 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 always found it easiest to put the records in a SQL database so you could compare the tables with a query that shows you what records are duplicated (some queries I’ve used a lot over the years here).

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. As you could imagine, if you deleted more child records, you’d have to import all of those records as well.

Backup & Restore Wrapup

The backup and restore features give CRM administrators the ability to restore records in the case of an accidental deletion of records.  Here’s hoping you never have to use that power.

If you want to know more about Dynamics 365 contact us at solutions@stoneridgesoftware.com. If you have further questions about this post feel free to comment below.



Источник: https://stoneridgesoftware.com/how-t...5-crm-modules/