Dynamics 365 Solution Management Best Practices
In the first two articles in this ALM series, we covered what Dynamics 365 solutions are and the difference between managed and unmanaged solutions. Now, itās time to talk about what makes solution management work well.
Creating a solution is easy. Keeping your changes organized, testable, and understandable over time takes a little more discipline. Fortunately, a few simple practices can make a big difference.
Use More Than One Environment
At a minimum, your Dynamics 365 setup should include two environments:
- Production
- Sandbox/Test
Your Production environment is where users are working every day, adding and updating real business data. Your Sandbox is where changes should be built and tested before they reach those users.
Why does this matter? Because even a small change can have unintended consequences. A Power Automate flow might update the wrong records. A workflow could behave differently than expected. A form change could make something important harder for users to find.
Testing changes in a separate environment gives you a chance to identify those problems before they affect Production. It also gives you room to experiment without interrupting users during the workday.
Package Your Changes in Solutions
If a change is going to move between environments, it should be organized and packaged in a solution. Instead of manually recreating a field here, a form change there, and a business rule somewhere else, you have one solution that represents the enhancement.
Not only does it provide a more controlled way to manage updates, but it also creates consistency in your ALM process. Changes are built in a solution, tested as part of that solution, and eventually moved forward as a solution.
Once youāre consistently using solutions to package your changes, the next question is what should go into them.
Keep Your Solutions Focused
You should only include all components and metadata when it is necessary. Otherwise, less is more when it comes to your solution files.
Itās best to include the components you need rather than every form, column, relationship, view, and other piece of metadata attached to that table. Keeping a solution focused makes it easier to understand what belongs to the project. Further, it lessens room for errors to occur.
This is one of those small habits that becomes increasingly valuable as your Dynamics 365 environment grows.
Establish Naming Conventions
Naming conventions may not be the most exciting part of ALM, but they are incredibly useful. Power Automate flows, classic workflows, business rules and other components can pile up quickly. Without a naming convention, you can end up with names that provide very little context about what a component does or why it exists.
A consistent naming approach makes components easier to:
- Find
- Understand
- Troubleshoot
- Maintain
The exact naming convention matters less than having one and using it consistently. Your future administrators (and probably your future self!) will appreciate it.
Have End Users Test Your Changes
When you implement a change or addition to your Dynamics 365 environment, it will work. You likely have System Administrator permissions, so by default you can see and edit everything. However, can your end users access it in the same way? Did you remember to add access to the security role your end users have? Itās a good rule of thumb to have your end users test for access, accuracy and matching expectations before moving changes into Production. They may catch things that an administrator or maker does not.
Be Consistent
None of these practices are particularly complicated. Good solution management does not start with an elaborate ALM process. It starts with repeatable habits:
- Use separate Sandbox and Production environments.
- Package your changes in solutions.
- Keep your solutions focused on the components that actually need to change.
- Use consistent naming conventions.
- Have users test and verify changes.
The value comes from doing these things consistently. As your Dynamics 365 implementation grows, that consistency makes the system easier to understand, easier to maintain, and much safer to change.
There is one more solution-management practice that deserves a closer look: publishers and prefixes.
Publishers help identify where custom components came from and can make a big difference when you are trying to understand a system that has been customized by internal teams, partners, ISVs or Microsoft. Weāll cover that next in the ALM series.
