It’s the month of bats, pumpkins, ghosts and skeletons. MVP Alex Shlega launched a series of blog posts where he encouraged the community to reveal stories which might help others, with input what NOT to do in Power Platform deployments. You’ll find his first post here. Best Practices is something that I am a big advocate of. Consistency and maintainable solutions are hard to accomplish without it. If you are more than one person working with a solution you simply need a common way of working. In this blog post I will share some thoughts around the subject and I might also have one or two skeletons to dig out from the closet and bring to the Halloween party.
We all were newbies at some point and at that point, things tend to more easily end up as skeletons in our closets than when you have gained some experience. Experience does not always do the trick though, but it helps because hopefully you will figure out what works well and not over time and in the meanwhile you can document your own Best Practices. New features and technologies come to us almost on a daily basis therefore it’s important to revise your Best Practices when needed. Below are a few different things that might cause problems in Power Platform deployments and throughout this post I will tell you about some skeletons as well as how I connect all the below parts to Best Practices.
- No ALM routines in place
- Not knowing what’s next and not
- Not cleaning up after oneself
- People and misunderstandings
Before we go into the skeleton details, here are a few words about Power Platform and Best Practices.
About Best Practices
Best Practices comes in different levels and might differ from organization to organization and project to project. Most importantly, you should work according to a Best Practice and solutions should NOT just end up as they end up because you did some trial and error. We have Best Practices from Microsoft. Whatever area you are working in, read the Microsoft Docs about that area and find out the recommendations from Microsoft.
Create your own Best Practices. Usually we get guidelines from Microsoft, at the same time it is possible to build your solutions in different ways and there might not be a “correct” one way of doing things. Your first guidance here might be that when you build solutions, you only do configuration and development which are considered as supported and if there are any exceptions to this it should be with crystal clear instructions and checklists to follow. Sometimes it might be hard to tell what’s supported and not. A good rule of thumb is: Is this documented by Microsoft? Yes, it’s supported. No, it’s probably not supported and you should avoid it. Using unsupported stuff means things might break when new updates arrives without you getting a warning about it and it also means Microsoft support might not help you fix what’s broken/figure out a solution.
Here follows examples of what you can include in your Best Practices. Naming conventions, for Dataverse tables, columns, relations, canvas apps, cloud flows etc. Look at how Microsoft has named their components in their first-party apps, look at Microsoft’s recommendations and then figure out your own strategy. When to use what, e.g. Low-Code or Pro Code? Plugin, Custom Workflow, Logic App or Azure Function… Business Rule or JavaScript… etc. There are often many different ways towards one goal but which one is best under what circumstances? ALM, solutions, deployments, temporarily workarounds which are needed when OOTB ALM routines are missing. How-to guidance which is not documented (supported stuff of course).
For Pro Dev parts it’s also a good thing to have a common Code Way of Working. Are we using TypeScript for client side scripting? How do we deploy web resources? Are we using Sparkle XRM? Should we have a “template” project? How do we write plugins? Should we have our own framework on which we base all plugin development so we do not have to redo the most common tasks over and over again in our code?
Now I will tell you about some things I have seen when people don’t have Best Practices in order. Working outside of solutions and all tables get the _new prefix. People creating new columns for Dataverse tables and use schema names in Swedish, even though the base language is English and translations should be in Swedish instead. Old columns not used anymore are still there. Re-purposing, e.g. using OOTB tables or columns for something other than what it is meant for. Why is this a problem? You will end up with solutions which are ugly behind the scenes and that will show when someone e.g. creates reports. It might also cause big confusion maintaining such a solution over time.
Is this a skeleton in my close? Yes. We were all beginners at some point. Let’s just say that when I was working with MSCRM 3.0 and 4.0 deployments Best Practices was not the first thing I thought of.
No ALM routines in place
Environment strategies, how to work with solutions, what publisher and prefix you should use, when to use pipelines, where to store code, solutions, icons, using pipelines to automate deploys and save your work in different versions. This is a big and important area and it’s not something you learn everything about from one day to another I would say. Best Practice within this area is best gain by taking part of MS Docs and getting yourself experience from working in different projects.
This is a big and nasty skeleton in my closet! When I first started my Dynamics CRM journey, I did not think that much about ALM routines. Of course we had different environments application servers / SQL Servers for DEV, TEST, PROD also back then and moved solutions in between, but to be honest, in the very beginning, I did not use a versioning control system. It was first when I met with Jonas Rapp that all fell into place, code and solutions, icons etc. were saved in Azure DevOps (or rather TFS back then).
Another thing that’s related to ALM is the creation of environments. You must NOT be sloppy when creating a new environment. There are certain settings which cannot be changed after you have created an environment. Base language, currency and if you choose an environment with Dynamics apps or a plain Dataverse. What if you create development and test environment and later when it is time to create the production environment you chose something wrong? Then you migrated data to the production environment, did lots of tests, and thought you were ready to go live but then you realize the environments have not been created in the exact same way. Perhaps the admin role see certain Dynamics parts in there or translations looking spooky. Is this a skeleton in my closet? Let’s just say it’s based on a true story.
Not knowing what’s next and not
Your Best Practice should include keeping yourself up to date! As already mentioned, a lot changes all the time. New features are coming, other features become deprecated. We have release waves, features in Public Preview and if you are new to the platform it’s not always easy to understand what you can use or not. You might use code and develop something and then there comes a new OOTB feature which gives you similar functionality as what you have already built and it would have been better to wait for that feature. You might use something that is not GA yet and you import it to Production and go live with it and then when it becomes GA, there are big changes to the feature and you will need to redo the whole thing.
Another aspect is features (and code parts) that becomes deprecated. Not knowing about that can end up in a catastrophe, with customers having their functionality broken. You might see a feature which seams to cover a certain user requirement, but when you have implemented it you realize that that feature was deprecated. Here, you will need to be up to date with Release Plans and the parts of MS Docs which reveals what’s deprecated. It’s also a good habit to follow the Power Apps blog in order to find out when something is being deprecated. You can use the Power Apps Checker in Maker Portal for your solutions and it will give you a hint if you have used something in your code which is not OK.
My skeletons for this part. Well, I would like to think that I am quite good at keeping up with what’s new, after all, I do like to read Release Plans and I am one of the curators at Power Platform Weekly. It can happen to the best though. 😉 Sometimes we know what’s next, sometimes we don’t. E.g. I used this tip from CRM Tip of the day and created a child flow to get my environment variables and then just shortly after, we were all of a sudden able to reach environment variables directly from the flow!
Not cleaning up after oneself
Your Best Practice should include cleaning up after yourself. If you add columns and then decide to change column type so you create a new column and do not delete the old one, you might end up with 10 or 20 such columns if you don’t have a habit of cleaning up after yourself. I don’t know about you, but I’ve seen people having as Best Practice to put a Z in front on a column when it was not needed anymore, for the column to be placed in the bottom when you make searches e.g. Also I’ve seen “Some Column Name (do not use)”. You don’t need to do that anymore! Even if you work in managed solutions, you can import and upgrade and the parts that have been removed in your DEV environment will be deleted also in the TEST and PROD environment.
The same goes for code. Perhaps you have created some plugins and then for some reason end up not using that business logic, don’t create a habit to just disable the steps in Plugin Registration. Same if you have had JavaScript in a web resource and later on remove that because it becomes possible to do the same thing with low-code, don’t just disable the events. Another thing with code. What do you think about seeing lots and lots of code lines being commented out? Instead of removing the code parts that you intend not to use anymore. That’s one reason why we have versioning and our code in Azure DevOps / GitHub, we can remove those lines and still be able to go back to it later if we for some reason change our mind.
My skeletons here, well, I like order and I have no problem with reminding others about cleaning up after themselves. However, of course there have been situations where I’ve been under time pressure and have not cleaned up enough after myself.
If you don’t have time to do it right, when will you have time to do it over?
John Wooden
People and misunderstandings
Why not create your own Best Practice for the softer parts as well. People, very important pieces of the Power Platform journey puzzle! This is most often the hardest part. Learning about technology that’s one thing. Learning about understanding different kind of people, might be trickier. Sometimes you work in a project where everything runs smoothly, everyone knows their roles and what’s expected from them. Everyone has a clear understanding for the roadmap and the goals you are working towards. Sometimes it might be a bit messy and unstructured and that’s ok, at least in the beginning and you can always try to structure things better.
What if that unstructured way of working and confusion continues? Another thing to bring up here is misunderstandings about what to build. Requirements gathering, this could be a whole chapter of its own, but I will just drop the WHY here. Often we need to discuss more about the WHY do you need this? To make sure we do not add anything just because that is how it was in an old system or that’s how they always did it. If we don’t understand the WHY it’s also a risk that we build the customization in a way that will not be useful for the end user. I am mixing a bit of project management and change management here. Anyway, I will just drop the link to someone who can help you getting started with Scrum for Microsoft BizApps, and hopefully it can be of help when it comes to structure your projects a bit better. Neil Benson, Customery.
Do I have skeletons here? Have I worked in these type of projects where there’s a “We – Them” feeling, expectations are unclear, there is a lack of roadmap and goals? Yes. However, it takes more than one person to cause this kind of mess so I consider it as not just my own fault. 😉 Note to self: Communicate concerns and risks from your point of view at an early stage and also have in mind that people are more complex than technology.
Conclusions
There are many things that can go wrong in Power Platform projects and a lot of things you will learn along the way getting more and more experience from gathering requirements, designing and building solutions and working with this platform. Start you own Best Practices collection and make sure to keep it updated. If you’re new to the platform, I would recommend not only training, but also to make sure you have someone to ask for advice. There are many Microsoft Partners out there and there are also both global and local Communities where you can ask questions and discuss around these topics. Get involved!
As Microsoft promotes this Platform as everyone can built apps etc. working with and communicate around Best Practices become even more important as organizations are starting to build more themselves. They could then need someone who have worked with the platform for years helping out with setting the Best Practices. Softer parts as project methodology is not to be forgotten.
This was my contribution to the Halloween Party. Don’t miss the ItAintBoring PowerPlatform Chat with Alex Shlega, on the 26th of October!
Read more
MS Docs
New home for experimental features
Documentation on experimental features
Important Changes Coming
ALM with Power Platform
Adoption Best Practices
Admin and Governance Best Practices
Nurture Best Practises
White Papers
Power Apps Canvas Apps Coding Guidelines and Standards
Other initiatives
Power Platform Adoption Framework
Cover photo by Clément Falize on Unsplash.
Carina M. Claesson 
1 thought on “Skeletons in the closet – Power Platform Best Practices Edition”