Advanced Power Platform Solution Topics

This post is a continuation of our prior post Application Lifecycle Management for Power Platform

What’s Your Flavor: Managed vs Unmanaged Power Platform Solutions

In Microsoft’s ongoing added sophistication of application lifecycle management to the Power Platform, they have brought the concept of Managed and Unmanaged to Power Platform Solutions:

• Unmanaged Solutions are used in development environments while you make changes to your application.  Unmanaged solutions can be exported either as unmanaged or managed (exported unmanaged versions of your solutions should be checked into your source control system) as they are your Microsoft Power Platform source assets.
• Managed Solutions are used to deploy to any environment that isn’t a development environment for that solution. This includes test, UAT and production environments.  Managed solutions can be serviced independently from other managed solutions in an environment.  As an ALM best practice, managed solutions should be generated by exporting an unmanaged solution as managed and considered a build artifact.

I think of Managed Solutions as sealed packages that have been deployed, typically, into a production environment and Unmanaged Solutions as open/community packages for development and testing.

Things to keep in mind about Managed Solutions:

• You can’t export a managed solution!  Since Managed Solutions are the means by which completed production software is shipped, this fact is consistent with an intentional ALM strategy.
• When a managed solution is deleted (uninstalled), all the customizations and extensions included with it are removed
• You cannot edit components directly within a managed solution; to edit managed components, first add them to an unmanaged solution.  This action creates a dependency between your unmanaged customizations and the managed solution.

More Power in Creating, Exporting and Importing Solutions

The experience is a bit different between Managed and Unmanaged solutions with Unmanaged solutions generally providing more latitude (but less rigor and control).  When you import an Unmanaged solution, you add all the components of that solution into your environment and cannot delete the components by deleting the solution.  Note that if your starting solution contains components that you have customized, your customizations will be overwritten by the state of the components in the imported unmanaged solution (note on top of this note: you can’t undo this).

The solution import process is similar to importing a standalone Power Automate Flow (as point of reference) by uploading a ZIP file package which the Power Platform will hydrate into the selected environment in the background.  Following this operation you will now have a new Solution at the top level list that you can drill into.

Deploying a Solution/Moving Between Environments

One of the fundamental capabilities of Power Platform Solutions is that of environmental deployment – in most scenarios this is analogous to deploying and releasing full-code solutions with the exception that Power Platform Solutions are not built/compiled in the traditional sense.  In a mature Power Platform arrangement, one will have “lower” environments for development and staging along with “higher” environments for production with Solutions elevating through their lifecycle.

While Microsoft has recently released Azure DevOps pipeline steps to enable automated Power Platform deployments (that’s really what you are doing when you move across environments), this operation has historically been carried out by teams in a manual process.  While we will cover Azure DevOps-based deployments in future posts, the following material covers manual solution deployment steps.

Our first step will be to export the solution, in which our most important decisions will be selecting a version number and a Managed or Unmanaged package option:

In this example, we are deploying a not-ready-for-production early version of a solution from a development to a staging environment – this explains the low version number and selection of Unmanaged for package type.

Now that you have your exported Power solution, navigate in the Power Apps portal to the environment that you intend to deploy the solution to and click the “Import Solution” button in the top navigation row.  Simply select the solution zip file and clicking “Next” and allow the portal time to unpack the uploaded zip file into the selected environment.

Don’t worry, we’ll dig into more bells, whistles and options on solution deployment next.

Updating a Production Solution

During the lifetime of a digital solution, there will be multiple junctures where you need to update an existing managed solution – this can be due to bug fixes, small feature additions or large next-version upgrades.  In a controlled ALM scheme, a team will change or add a feature in a lower environment and need to move it to production without starting a whole new solution.

To carry out a controlled update of a Power Platform Solution, start by opening the unmanaged solution in the solutions source/development environment and create the new features, add or remove components and overall make the functional changes that you want.  Upon release, increment the version number when you export the solution (as a managed solution since we are going to production!).

Next up in the release train is the application of the updated/upgraded solution into the target (typical production) environment.  The import procedure for an updated solution is similar to installing a new managed solution but with the addition of a few different options.  On the command bar, select Import and browse to the compressed (.zip) exported solution file as before when you first deployed the solution.  Since this is an update to an existing solution you will be greeted by a yellow strip indicating “This solution package contains an update for a solution that is already installed. To upgrade the solution, select Next”.

To view additional options, expand Advanced settings, and then select from the following solution action options:

• Upgrade This default option upgrades your solution to the latest version, rolling up all prior patches in one step.  Any components associated with the previous solution version that are not in the newer solution version will be deleted.  In addition to this being the default option, I consider this the recommended option as it will ensure your resulting configuration state is consistent with the importing solution and remove the “solution junk” of components that are no longer needed.
• Stage for Upgrade This option upgrades your solution to the higher version but defers the deletion of the previous version and any related patches until you apply a solution upgrade later.  This option is a bit of an outlier option but is a great option to have both the old and new solutions concurrently installed in the event that you have other cleanup actions like data migration before completing the upgrade.  Applying the upgrade will then behave exactly the same as a direct Upgrade option.
• Update This option replaces your solution with this version.  Components that are not in the newer solution won’t be deleted and will remain in the system.  I don’t recommend this approach as your destination environment will differ in configuration from your source environment and could cause issues that are difficult to reproduce and diagnose.

Managed customizations are always imported in a published state, so there is no need to publish customizations after the Import described in this scenario.

Understanding Version Numbers for Solution Versions

SemVer (short for Semantic Versioning) is a time-tested standard in full-code software development and maintenance to track and indicate the vintage of any given piece of software.  By convention Microsoft has adopted SemVer for Power Platform Solution versioing.

With the SemVer standard, a solution’s version has the following format: major.minor.build.revision.  An update must have a higher major, minor, build or revision number than the parent solution – in some fashion the updated solution needs to be newer than the solution it replaced.  For example, for a base solution version 3.1.5.7, a small update could be a version 3.1.5.8 or a slightly more significant update could have version 3.1.7.0.  A substantially more significant update could be version 3.2.0.0 (a full new minor version or “point release”).

There’s an App Store for That

Well, actually, it’s called AppSource and it is a marketplace where Power Platform developers can go shop for solutions and components tailored to your problems space and/or industry that utilize the underlying Power Platform ecosystem.  Before undertaking development of a portion of your solution or component that strikes you as “it seems like someone would have already solved this problem”, it is definitely worth taking the time to look in AppSource first.

What Are the Gotchas About Solutions?

In the real world, every piece of technology has one or more major “gotchas” whether it’s pieces of the technology not being quite as automagic as is advertised or additional bits of work required than is described by the vendor.  Power Platform Solutions are pretty true to the promise they deliver, but given that they are relatively new, there are a few gotchas.  The following limitations apply to the use of Canvas Apps and Flows within Solutions:

• Canvas app instant flows must be created from a Power App already in a Solution; adding this type of flow from outside a solutions is blocked at this time
• Canvas Apps won’t display in the classic solution explorer (use the modern experience)
• Flows created from solutions will not be displayed in the “Team Flows” list; they must be accessed through a Solution
• You can’t add an instant flow into a solution if it was created outside of a solution and the trigger is set to Manual
• Flows in solutions do not support delegated authentication. For example, access to a Flow is not automatically granted based on having access to the SharePoint list the Flow was created from.
• Custom connectors created outside solutions cannot be added to solutions at this time.
• Flows using connectors that are ‘indexed’ cannot be added into solutions

There’s more!  We have one last post in this series – Power App Components – stay tuned and we will post a link to it when it’s published.

Interested in our Power Platform Development Services?