Best Practices for Documenting, Cleanup, and Testing in Microsoft Dynamics 365

I’m halfway through my Best Practice series and I am loving the feedback that I’ve received so far. For this blog, I’m going to touch on three very important best practices that you should follow. Not just with Dynamics, but with any system that you work with whether it be implementing or just administering and maintaining. I’m going to discuss best practices for documenting, cleaning up, and testing.

Documenting

A wise man once said, “If it isn’t documented, it didn’t happen”. When thinking about documentation, do you cringe? Honestly, I do. However, every day I begin to understand its importance more and more.

Not only have I benefited from the documentation that others have prepared, but I’ve benefited from my own documentation. It’s tough to remember everything that you’ve set up and configured in a system or even why you set it up the way you did. Documentation will help answer those questions.

When creating documentation, it’s best to have a template. You can have different templates for different types of components. Not everything will always fit into the same outline, but do your best to simplify it as much as possible. For example, you could have a template for configuration documentation and include workflows, business rules, business process flows, etc. Using templates will allow for conformity so everyone is documenting their items in a similar fashion.

If you always document what you do, creating end-user documentation and training materials becomes a breeze. If you’ve already documented a process with screen shots and steps, you can reuse a lot of that information to quickly create a “How To” guide for an end user. Again, documentation will take the guess work out of wondering why you did something and who you did it for.

Cleanup

Do you have fields or other components in your system that start with the letters zz or xx to force them to the end of the list when shown alphabetically? How about fields that start with DO NOT USE or DELETE ME. If you do, you are not alone. When testing, sometimes we tend to set up something temporarily to assist us with testing our new functionality. Once testing is successful, we document and deploy, but we forget to go back and remove our temporary items.

As a general best practice, you should always clean up after yourself if you create temporary items. In Dynamics, how often have you created a workflow called “test” just to see if it’s possible to add a condition or add a step to create a certain record? Once you determine if it’s possible or not, do you just close out of the window? This leaves your “test” workflow in the system. Will you remember in three months from now what you were testing and if it’s OK or not to delete the workflow?

System administrators don’t always remember why they created different components for testing. Then three months later, when you try to delete something, you realize it’s dependent on something else. You come to find that someone else used your test item to test something they were working on. You’re faced with wondering if it can be deleted or not. This is why it’s always best to clean up your temporary test items right away.

Cleanup isn’t always going to include test items either. If you retire a process or decide that you no longer need 20 fields on an entity that you created for a division of the company that’s no longer there, remove them from the system. You have the ability to export data as a back up for future use, but if you don’t need it, then get rid of it. Try to keep a minimalist mindset when it comes to maintaining your system. Don’t be a configuration pack rat.

TEST TEST TEST

“I know what I’m doing. I can make this change in less than five minutes and my users will be happy.” And then five minutes after that, you start getting phone calls because a business rule is breaking because you removed a field from a form that was part of a business rule that another system admin deployed yesterday.

Hopefully, you see how things go hand-in-hand, such as documenting and testing. Don’t make the change for your user without testing and without looking at existing documentation. Even without existing documentation, just don’t deploy changes without testing.

We use an alpha, beta, system, user testing approach. For alpha testing, the person making the change will test and document. The documentation passes to another technical person who beta tests. From there, the change is tested as part of a broader, system test, usually by yet another person, who may not be as technical as the first two. Once the change passes the first three tests, the end-user tests the functionality. At any point, if testing fails, it starts back at alpha testing.

Moving Forward

It may seem tough and time-consuming at first to follow these best practices. It will take you more time to complete some of your tasks when you have to test and have other people test as well. Everyone seems so busy nowadays and you might be worried you’re using someone’s valuable time. Don’t be. It’s OK. Testing is not a waste of anyone’s time and neither is documenting.

Consider the time you’ve spent researching why something was done. Consider the time you’ve spent fixing an issue that wasn’t tested correctly. I’ve seen untested changes that caused weeks of bad data to be generated and the data ended up having to be updated manually. If even two people had tested their change before it went live, one person wouldn’t have had to spend two weeks updating data.

In the end, if you adopt these best practices and get into a habit of following them, then you won’t run into as many issues that are a fire drill to fix. You’ll have seamless end-user adoption because they loved the system when you implemented it and they’ll continue to love it because you’re enhancing it to support their jobs.

Contact Us!

If you’d like some assistance with cleaning up your existing system, documentation templates, and best practices, or with a solid testing plan, please contact us today. We’ve helped several companies with these tasks by setting them up with best practices to follow that fit their business needs.

If you’ve missed any of the blogs in my series, you can work backward starting from my last blog on Best Practices for Forms and Fields.

Beringer Technology Group, a leading Microsoft Gold Certified Partner specializing in Microsoft Dynamics 365 and CRM for Distribution. We also provide expert Managed IT Services, Backup and Disaster Recovery, Cloud Based Computing and Unified Communication Solutions.