A recent issue we came across was dealing with the address suggestion that is a feature of the Sales Hub and Field Service app in Dynamics 365. We have a custom security role that was giving access to all of our sales people. When editing or creating an account after the user types in the street 1 and city/zip the address suggestion modal is supposed to appear. During testing we were able to see with system admin access it was still working which narrowed it down to a security issue. 

A common request we receive is to format phone number fields on Accounts, Contacts, Leads, or any other table that it is needed within CRM/CE. You have a number of options when choosing how to format your phone numbers. If you are on the latest and greatest CRM/CE versions you can use the functionality of Microsoft Flow to create a flow that will accomplish this. I still prefer to use JavaScript that will run on change of the different phone number fields. Below is an example function of how this can be accomplished.

Another option you may want to consider if you have any integrations that run is to create a plugin that runs PreOperation to format the phone number fields. The advantage to this is it will run when anything is added to CRM/CE where JavaScript relies on a user to be physically typing in the phone number. Disadvantage is the phone number isn't displayed formatted until after you click Save.

Recently a client emailed in with an urgent message, "I have an issue that I need help with ASAP. I just did an update today that accidentally overwrote a bunch of accounts information and I wanted to know if there's a way to undo it.". After emailing back to get a better look at what actually had been updated, we determined that over 5,000 accounts had been updated with the same name, address, and other custom fields. This first illustrated the importance of having auditing turned on in your environments but also having someone experienced with data migrations importing data into CRM. There are a few tools out there currently, such as XRM Toolkit, that have a rollback tools that allow you to roll back an entity using the audit history records but these tools require you to have the GUID(unique identifier) and is not in bulk.

With it being 5k records needing to be rolled back, it wasn't realistic to do this account by account. What I ended up doing was created a console application that retrieved the effected accounts and their audit history. Then figured out old values vs new values and did the update. This took a little digging to figure out since it isn't very well documented by Microsoft how to get the audit history. Here is a partial code snippet. We used this console application to get all effected accounts updated with the original data and they couldn't have been happier with us. If this looks like a foreign language to you and you are in a same predicament give us a call! Or if you have questions on getting your audit history configured so you don't run into a situation where you are unable to rollback something that a user accidentally​ did.