Power Platform ALM Dos and Don’ts

Carina ClaessonPower Apps1 month ago10 Views

Do you build data models and custom apps with Dataverse in the background? Do you extend Dynamics 365 apps with custom columns, forms, views, and business logic? Do you automate tasks by setting up cloud flows, for more than personal use? Are you exploring creating your own agents with Copilot Studio? Do you create dual-write mappings?

If you answered “yes” to any of those questions, how familiar are you with solutions? If you’re not, it’s time to step up your game! If you are, you might have some dos and don’ts to add to my list. This post started out as a Solutions Dos and Don’t and it turned out wider. Choose the right way, not the wrong one!

ALM for Power Platform

To truly understand solutions, you need to get the bigger picture. What you build consists of various components. These can include parts that make up a Dataverse data model, such as tables, columns, and relationships. It can be apps, cloud flows, security roles, Dataverse plugins, and more, even Copilot Studio agents. Also dual-write mappings, which is a story of its own! All of that should be created within a solution.

So we can group what we build together in a solution, but why? Well, the powerful part comes when you have dedicated environments in place. E.g. for development, test and production. Solutions then let you group what you have built and move it to other environments. Make it sustainable in the long run!

Environments are provisioned in Power Platform Admin Center. Below I have a Developer environment only (this is an environment for personal use, not to be mixed up with a developer environment as in dev, test, production, such a dev environment would have had type Sandbox).

Now we’re ready for the Dos and Don’ts!

ALM for Power Platform Dos and Don’ts

Let’s start with some general Dos and Don’ts, where do you start and what should you think of? Can you put a in front of all the Dos already?

Dos

Familiarize yourself with Environments – learn about the different types
Establish your Environment Strategy – How many environments, when/how?
Select wisely – Base Language, Currency, D365 apps are unchangeable settings
Be aware of settings not changed super easily – Region
Know that the setting Managed Environments requires certain licenses
Decide on deployment processes – You’ll need good routines
Consider automated deployments – Save time, get automatic version control
Familiarize yourself with concepts Unmanaged vs. Managed & Solution Layers
Know if components are “solution-aware” – data is not, some components not

Don’ts

Make all configurations directly in a production environment – very risky way!
Establish dev & test but continue to make small changes in test & prod
Use manual deployments and skip version control of your solutions
Continue using manual deploys as your solution grows – someone’ll mess up
Use preview features is production – might mess up your ALM process
Assume solution awareness for new features – Not always the case
Assume full ALM story in place for new features – Some parts might not be
Mix up Managed Solutions and Managed Environments – 2 different things!

Solutions can be viewed from Maker Portal, from Copilot Studio or the Power Automate site. It’s just different UIs, you’ll see the same solutions. Are you traditionally from team Managed or Unmanaged? The recommended way is managed in target environments!

Solutions Concept Dos and Don’ts

Environments are in place, all you need to do now is know how to work with solutions! Do you have one, two or more in the same dev? One is recommended! Are you using managed solutions in target environments? That’s best practice!

Dos

Always work in a solution – get your prefix, know components get deployed
One unmanaged solution/dev environment – avoid dependency issues, except:
Custom connector + cloud flows utilizing the connector – split in 2 solutions
SLA’s in own solution – Gets deactivated after you’ve imported the solution
ARC’s in own solution – input from fellow MVP Bendikt Bergmann/MS Support
Use one single solution publisher for all your solutions across your environments
“Upgrades” in order to delete from target environments what’s not in dev
Use “Set preferred solution” – e.g. new feature Start with a Plan utilizes that
Continuously make sure all components needed are in your solution

Don’ts

Let multiple solutions share components in the same dev environment
Add what’s NOT necessary, e.g. column on OOB table -> add table & column only
Let old customizations remain within your solution – messy & hard to maintain

Today in Maker Portal, I noticed setting your preferred Solution was very visible and hard to miss! I could close that message down though.

Messy Environments and Solutions?

In case you have ended up with a mess, unmanaged in all environments and/or many solutions, maybe even inconsistency between environment. Then:

Dos

Consider cleaning up the mess and if you want to do that:
Create a new solution, add all needed components (still – only what’s used)
Remove the unmanaged solution from target environments if same name
Import as managed in target environments
Check the official documentation for more guidelines

Don’ts

Continue adding to the mess by introducing new solutions
Give up because of dependency issues – try a Microsoft ticket if too tricky

Apparently I don’t practice what I preach, this is how it looks in my personal environment currently. But oh well, to my defense, this is my playground and not a developer environment (well it is, but TYPE Developer, not dedicated ).

Stay curious and learn more!

It’s always beneficial to stay curious. In this ever-evolving world where re-imagination has become commonplace, what should you think of? What does Release Waves have to do with solutions? Well, the new features that roll out may be solution-aware or not. Eventually they will be ready for you to use in solutions!

Dos

Familiarize yourself with Release Waves and how new features are rolled out
Try out Power Platform Pipelines – Always good to know about your options
Learn about Power Platform Build Tools for Azure DevOps – More flexibility!
Explore GitHub Actions for Microsoft Power Platform
Keep mind open for new ALM related approaches – e.g. Dataverse Git Integration
Follow the LinkedIn group dedicated to Pipelines in Power Platform
Visit ALM for Power Platform every once in a while

Don’ts

Miss the possibility to try out Early Access features of Release Waves
Mix up Azure DevOps pipelines & Power Platform Pipelines – not the same
Stick to your old habits, manual export and import – learn to be efficient
Fumble in the dark, ignoring new features – instead stay curious!

Pro Tip: Did you know that if you want to get started with building solutions to publish on AppSource you’ll use the solution concept and also something called Package Deployment tool. Nowadays that’s used also when you certify connectors.

See my posts about AppSource from the past. Also see the official documentation, Publish your App on AppSource and Packaging a Connector for Certification.

Fellow MVPs’ content

Benedikt Bergmann made a post Dataverse Solutions Explained. Follow his blog for more ALM related posts. He even wrote a book about ALM for Power Platform! Jonas Rapp wrote a post ALM a la Rapp. All former MSCRMers have their own personal adventures, “love-hate” relationships with solutions and related it seems!

There is also a new video from Sean Astrakhan. It’s both entertaining and contains great explanations to why you should have one and the same publisher and preferably work in one and the same solution. There’s also a teaser of an upcoming video about environments