Category: Power Platform

This article is part of the Working with Power Automate Solutions series and of the larger Working with Power Automate series I am writing on my experiences working with the Power Automate, which is part of the Power Platform from Microsoft. I also have a related series of articles on Power Automate with Microsoft Dynamics 365 BC.

As mentioned in the article where I introduced solutions, when you have a solution which is ready for deployment, or even where you have made changes to the solution since it was last published, then the solution should be published for the implementation of Application Lifecycle Management (ALM) .

While technically speaking, a solution which does not use the Common Data Service (CDS) does not need to be published, I’d generally recommend following best practice of publishing all solutions.

For the work I have been doing with Power Automate, involving Business Central and approvals, I am interacting with the CDS as the approvals store the history and status of pending approvals in CDS.

To publish a solution, open the solution and click the Publish all customizations button at the top of the solution page:

Once the publication is complete, a green status confirmation bar will be displayed towards the top of the screen:

With the solution published, it can now be exported (although I should not that the export process itself does prompt for the solution to be published, so you could publish from there instead of using this method).

Over the next few articles, I’ll take a look at exporting and import the solution as both an unmanaged and managed solution.

This article is part of the Working with Power Automate Solutions series and of the larger Working with Power Automate series I am writing on my experiences working with the Power Automate, which is part of the Power Platform from Microsoft. I also have a related series of articles on Power Automate with Microsoft Dynamics 365 BC.

To create a soltuion, log into the Power Automate website and, in the navigation pane to the left, click on Solutions; click the New solution button at the top:

Enter a Display Name for the new solution; the Name field will automatically populate with the same text, although with invalid characters (such as space, slash, backslash and asterisk, amongst others) automatically removed.

Select your Publisher.

The Version will default in as 1.0.0.0, although you can change this if necessary. Sometimes when working on pre-release versions I might make the version number start with 0, but for the very first release would return the version to 1.0.0.0 through Edit Settings before exporting as a managed solution.

When the new solution has been configured, click the Save button at the bottom of the pane; the list of solutions will update and show the new solution, ready for you to start using it.

This article is part of the Working with Power Automate Solutions series and of the larger Working with Power Automate series I am writing on my experiences working with the Power Automate, which is part of the Power Platform from Microsoft. I also have a related series of articles on Power Automate with Microsoft Dynamics 365 BC.

As I mentioned in the article on what a solution publisher is, in this article I am going to step through the creation of a solution publisher.

To do this, log into the Power Automate website and, in the left navigation pane, select Solutions; click the Publishers tab and then click the New publisher button at the top of the page:

In the New publisher detail pane, which opens on the right of the screen, enter the Display name, Name and Prefix; as you enter the prefix, the Choice value prefix will automatically populate, although you can change it by over-typing.

You can also choose to enter a Description giving a longer outline of who the publisher is; perhaps a tagline or mission statement.

Clicking the Contact tab allows you to enter the Phone, Email and Website as well as address details for the publisher. This is handy if you are a VAR or ISV distributing your solutions to clients or customers, because you can enter details of your support team.

This article is part of the Working with Power Automate Solutions series and of the larger Working with Power Automate series I am writing on my experiences working with the Power Automate, which is part of the Power Platform from Microsoft. I also have a related series of articles on Power Automate with Microsoft Dynamics 365 BC.

Every solution requires a publisher; if you don’t create one, then the solution uses the default publisher. My advice, very strongly so, is to create a solution publisher of your own.

A publisher serves several purposes.

Firstly, the solution publisher defines who developed the solution or app. The very first thing you should do when starting to work with solutions is to create a publisher.

Secondly, the solution publisher defines the prefix of the solution, which is used to avoid naming collisions. This allows solutions from different publishers to be installed into an environment without conflicts (or if none then at least with minimal conflicts).

While it is possible to change the solution publisher name and prefix, existing components cannot have their prefix changed; this means that changing the prefix of a solution means you will have components with two different prefixes in the solution.

Thirdly, the publisher of a solution owns the components within the solution. This means they can control what changes publishers of other solutions are allowed to make to the components of the solution.

In the next article of this series, I’ll step through creating a solution publisher.

This article is part of the Working with Power Automate Solutions series and of the larger Working with Power Automate series I am writing on my experiences working with the Power Automate, which is part of the Power Platform from Microsoft. I also have a related series of articles on Power Automate with Microsoft Dynamics 365 BC.

As I briefly mentioned in the last post, where I introduced solutions, there are two types of solution:

1. Unmanaged
2. Managed

Unmanaged solutions are used in development environments while the flows are being created or maintained. Unmanaged solutions can be exported either as unmanaged or managed; it is recommended that exported unmanaged versions of your solutions be checked into your source control system.

When an unmanaged solution is deleted, only the solution container is deleted; all of the unmanaged flows and other components remain in place.

Managed solutions are used to deploy to any environment that isn’t a development environment; this includes QA, UAT and production environments.

As an ALM best practice, managed solutions should be generated by exporting an unmanaged solution as managed and considered a build artifact. Managed solutions can be serviced independently from other managed solutions in an environment.

Some of the key features of a managed solution are:

• Managed solutions cannot be exported.
• When a managed solution is deleted (uninstalled), all of the flows and other components within it are removed.
• Components in a managed solution cannot be directly edited. To edit managed components, they must first be added to an unmanaged solution. When this is done, a dependency between the unmanaged customisations and the managed solution is created. When a dependency exists, the managed solution can’t be uninstalled until the dependency is removed.
• Some managed components can’t be edited. To verify whether a component can be edited, view the Managed properties.

Further information on solutions in general and the types of solution are available on Microsoft Learn.

This article is part of the Working with Power Automate Solutions series and of the larger Working with Power Automate series I am writing on my experiences working with the Power Automate, which is part of the Power Platform from Microsoft. I also have a related series of articles on Power Automate with Microsoft Dynamics 365 BC.

A solution is how you can implement ALM (Application Lifecycle Management) with Power Automate. A simple way of viewing a solution is that it is a container of related flows and other components (connections, environment variables, and so on) which are part of the same project, which makes it easy to find everything in one place.

Solutions can also be used to transfer their contents from one environment to another for deployment

An example of this would be an VAR or ISV, I work for a company which os both, creating a solution for a client on our internal systems, or in one of their sandbox environments, and then exporting the solution to then import into their QA environment for testing before then deploying into their production environment.

Solutions can, in very simple terms, be unmanaged, which means the components can be changed, or they can be managed, which means the components cannot be changed; a production environment should never contain an unmanaged solution. I’ll cover the types of solution (unmanaged and managed) in more detail in the next article of this series.

The table below outlines the actions with a solution which help support ALM:

Action	Description
Create	Author and export unmanaged solutions.
Update	Create updates to a managed solution that are deployed to the parent managed solution. You can’t delete components with an update.
Upgrade	Import the solution as an upgrade to an existing managed solution, which removes unused components and implements upgrade logic. Upgrades involve rolling up (merging) all patches to the solution into a new version of the solution. Solution upgrades will delete components that existed but are no longer included in the upgraded version. You can choose to upgrade immediately or to stage the upgrade so that you can do some additional actions prior to completing the upgrade.
Patch	A patch contains only the changes for a parent managed solution, such as adding or editing components and assets. Use patches when making small updates (similar to a hotfix). When patches are imported, they’re layered on top of the parent solution. You can’t delete components with a patch.

As I have a number of articles to write on Power Automate solutions, I’ve decided to break these out into a sub-series of the main Working with Power Automate series; they will appear as posts within both series in the order written, so you can easily access and read them from within either.

The series index, below, will automatically update if you’re reading the original article on azurecurve | Ramblings of an IT Professional. If you’re reading elsewhere, the original article, which will update automatically is here.

Working with Power Automate Solutions
What Are Solutions?
What Types of Solution Are There?
What is a Solution Publisher?
Create a Solution Publisher
Create a Solution
Publish a Solution
Version Numbering for Solutions
Exporting An Unmanaged Solution
Importing An Unmanaged Solution
Exporting A Managed Solution
Importing A Managed Solution
Change the Managed Properties of a Solution Component

This article is part of the Working with Power Automate series I am writing on my experiences working with the Power Automate, which is part of the Power Platform from Microsoft. I also have a related series of articles on Power Automate with Microsoft Dynamics 365 BC.

Power Automate is a service that can help you automate repetitive tasks to bring efficiencies to any organization; there are three types of flow in Power Automate:

1. Cloud flows – used when you want your automation to be triggered either automatically, instantly, or via a schedule.
2. Desktop flows – used to automate tasks on the web or the desktop.
3. Business process flows used to provide a guide for people to get work done. They provide a streamlined user experience that leads people through the processes their organization has defined for interactions that need to be advanced to a conclusion of some kind.

In this series of articles, I am going to be focused on cloud flows. In the next article, I’ll take a look at the types of cloud flow which are available.