Based on your feedback, Power Automate has two categories of enhancements that are improving the ALM story:

1. Solution cloud flow improvements
2. Core ALM improvements

Below are details about each enhancement category and information about what has recently been released, is being released, or is planned.

Solution Cloud Flow Improvements

Solution cloud flows are stored in Dataverse, so they are ready to take part in ALM and can be administered and managed via Dataverse APIs along with other Power Platform components.

A solution can contain flows, apps, tables, and more. Solutions are the mechanism for implementing application lifecycle management (ALM) in the Power Platform.

See Solutions overview, Microsoft Docs for more information.

Flows created in a solution or added into a solution can be referred to as solution flows or solution-aware flows. A typical use case is for customers to develop flows in a development environment and then move those flows to a test environment for isolated testing. After testing, the customer can then move the flows to a production environment. This process is much easier using solutions with all artifacts stored in Dataverse and leveraging the flexibility of connection references and environment variables. Solution flows are also easier to administer and manage since, once flows are in Dataverse, administrators can audit, query, and inventory them by querying Dataverse.

See Overview of solution-aware flows, Microsoft Docs for more information.

Recently released

• Users can see solution references on the flow details page – May 2022 – release plan item – Makers can understand what solutions a flow is referenced from and can quickly open those solutions.
• Solution cloud flows are shown in the My Flows list – June 2022 – release plan item – Makers can see solution cloud flows in the Cloud Flows and Shared with Me lists to easily find the most recently created and edited solution cloud flows. See documentation for more details.

Upcoming

• “Save As” on a solution cloud flow saves the new flow as a solution cloud flow, instead of a non-solution cloud flow.
• Makers create solution cloud flows by default when Dataverse is present.
• Admins and makers can migrate non-solution cloud flows into Dataverse and into solutions

Core ALM Improvements

In addition to getting cloud flows into solutions, there are several core improvements to make ALM easier as well. Most of these items are detailed in our release plans. 
Recently released

• Connection references show in the flow details page without a connection – Nov 2021 – release plan item – Makers can see all the connection references that a flow is using and items needing attention are highlighted.
• Connection reference names are unique by default – Dec 2021 – release plan item – Makers can differentiate between connection references.
• Makers and admins can change the owner of solution cloud flows – Feb 2022 – release plan item – Makers can easily adjust the ownership of solution cloud flows in Power Automate portal instead of going into the legacy solution explorer experience.
• Solution cloud flow exports are now source control friendly – Feb 2022 – Pro-developers and admins can now comment on specific aspects of a flow when it is checked into source control.
• Simplify how solution cloud flows are shared with other users – April 2022 – release plan item – Makers can more easily share solution cloud flows with team members.

Currently rolling out

• Solution checker warns if solution cloud flows are using connections instead of connection references – June 2022 – release plan item – Admins and Makers can be warned when solution cloud flows are not following ALM best practices.

Upcoming

• Flow ownership supported for Service Principals – release plan item – Service Principal users can own and run flows. There will be a separate blog post on this item when it is released.
• Send email notifications to solution cloud flow owners about key events – Makers get email notifications for key events including flow failures, throttling, edits, and suspensions.
• Use environment variables in any flow trigger – Makers can use environment variables in all flow triggers, with a few exceptions.
• Push environment variable updates into flows asynchronously – Makers updates to environment variable values will be asynchronously propagated into referencing flows.
• Warn makers if they are about to edit a managed flow and create an unmanaged layer – Makers are warned before creating customization artifacts.

To learn more about Power Automate ALM, see Overview of solution-aware flows. To learn more about Power Platform ALM, see Overview of ALM with Microsoft Power Platform.

We hope that you will find these improvements useful and thank you for your continued feedback. Happy Automating!

The post Making application lifecycle management (ALM) easier in Power Automate appeared first on Microsoft Power Platform Blog.

In this blog, I want to highlight some of the recent updates we are releasing in our platform for custom connectors. These changes are being rolled out, and will provide a better experience to enable a seamless ALM (application lifecycle management) for custom connectors. In Power Platform, Solutions are used to package components and deploy those components to various environment, customizing them as needed. The updates include:

• Users (makers) can now add any existing custom connectors to a Solution
• Users (makers) can create and use Environment variables in custom connectors
• Secrets used for OAUTH settings can be stored securely in Azure Key Vault
• Updated API documentation for custom connectors

With the above features, you can now easily enable end-to-end ALM for custom connectors. Any existing custom connector can now be added into a Solution. You do not have to start building your customer connector anew from inside a Solution. Environment specific values like API endpoints and OAUTH app details, can be externalized now in Environment variables and referenced by custom connectors. You do not need to update your custom connectors in different environments; and apps and flows targeting the custom connectors do not have to be modified in different environments. Finally, you can store your secrets using in your custom connectors in Azure Key Vault and use it via an Environment variable in your custom connector.

Let’s walk through an example.

We will use the Service Now custom connector available in our GitHub repo to illustrate these features, but you can use any custom connector.

First, we need to create the Service Now custom connector. You can sign up for a developer instance from Service Now if you need an instance. The Service Now custom connector supports OAUTH based authentication and there are certain configuration steps you need to do to enable that. It is fairly straight-forward though, and you can follow the documentation of the custom connector. You can watch this short video as well on how you can create the custom connector.

Next, we want to setup the connector so that we can externalize environment specific settings. In our case, we would want to externalize the Service Now Instance, and the OAUTH application details. Typically, if you are developing, you may be working on your own developer instance. In a production or UAT environment, you may want the connector to point to your production Service Now instance, and you may not have the necessary privilege to setup the OAUTH application.

To do that, lets create a Solution called “Snow Connector”, and add our custom connector. You can do that by selecting +Add Existing > Automation > Custom connector. You can see your custom connector in the “Outside Dataverse” category. Select the connector and click Add.

The next step is to create the Environment variables . To do that, select +New > More > Environment variable. Specify a display name, say SnowConnector_Instance, for the Environment variable and add the value which should be the instance name for your Service Now instance.

We need to add two other Environment variables for the OAUTH Client ID and OAUTH Client Secret. Because these are secrets, we will use the recently released feature of using Azure Key Vault as the secret store for these Environment variables. Create an Azure Key Vault account, add your secrets – one for the OAUTH Client ID and another for OAUTH Client Secret. Then, follow the instructions in our documentation to specify an access policy that will provide the Dataverse Application a read permission for secrets.

In your Solution, add a new Environment variable (called SnowConnector_ClientID) for the Client ID, specifying the Data type as “Secret”, the Secret Store as “Azure Key Vault”, and then add a reference to your secret specifying the Subscription Id, Resource Group name, Key Vault name and the Secret name.

Similarly, add another Environment variable (called SnowConnector_ClientSecret) for the Client Secret.

Because we are going to use the values of these Environment variables only in this environment, we want to make sure that the value are removed from the Solution. To do that, select the environment variable, scroll down to the Current value, select … > Remove from this solution.

The next step for us is to use these environment variables in our custom connector. To do that, edit custom connector and use the following formula @environmentVariables(“env_variable_name”). For our case, I updated the values for Host, and OAUTH security settings in our connector. For my Solution, this is:

Instance Name: @environmentVariables(“crd10_SnowConnector_Instance”)
Client ID: @environmentVariables(“crd10_SnowConnector_ClientID”)
Client Secret: @environmentVariables(“crd10_snowConnector_ClientSecret”)

Make sure you replace the Instance name at multiple places (Host, Authorization URL, Token URL and Refresh URL). The Client secret value is masked in the UI. See below:

Save your custom connector. And test to make sure that it is working.

Now, all you need to do is export the solution. For that, you go back to the Solutions list, select the “Snow Connector” solution, and click Export. Click Next > Export. Your Solution will now be exported and automatically downloaded as a .zip file.

You can then login to your test environment and import the Solution. While importing the Solution in the new environment, you can specify the values for the Environment variables. These values need not be the same as the one you used in the developer environment, but can be customized for the specific environment. For the Client ID and Client Secret, you can specify the value in the following format:

/subscriptions/{Subscription ID}/resourceGroups/{Resource Group Name}/providers/Microsoft.KeyVault/vaults/{Key Vault Name}/secrets/{Secret Name}

Once you are done with the import, you should be able to create a connection to your custom connector.

This walkthrough provides an overview of the end to end experience for packaging and deploying custom connectors across environments. You can leverage other ALM features like deploying the Solution from an Azure DevOps CI/CD pipeline by providing a deployment settings file as well.

There are still some limitations at the moment—

• Any change to an EV value is currently not reflected on the custom connector automatically. The changes are reflected only after an update of the custom connector.
• Environment variables in a custom connector can only be referenced from the Host/Base path and the security settings. Specifically, it is not supported in policies or within the operation definition.
• [Edit 2/10/2022] Environment variables using Azure Key Vault secrets can now cannot be deployed from an Azure DevOps and GitHub pipeline. Read the blog here.

Please try these features out, and do share any feedback you may have.

Happy Automating!

The post Easier deployments of Custom Connectors appeared first on Microsoft Power Platform Blog.

Application Lifecycle Management

Previously, we provided the ability to export and import a single flow from one environment to another environment. While this feature was useful for promoting individual flows between environments, it required many clicks to move multiple flows.

We have also received feedback from our customers regarding the ability to logically group related flows as they are being built and managing them. For example, you may have multiple flows that are part of a project you are working on. While working on, or managing these flows, you don’t want to have to scroll and search for these flows when you want to access them.

Solutions address deployment needs by allowing you to export and import a set of flows (and apps). In addition, you can organize these flows within a single ‘container’ which simplifies navigating and managing these flows.

Accessing Solutions

For customers who meet the environment prerequisites (see more below), a Solutions link will appear within the left navigation of the Microsoft Flow maker portal.

The Solutions experience will be loaded where we can find our deployed solutions. As part of this experience we can determine the Date it was installed on, if it is Managed externally, Version and the name of the Publisher.

Creating a new Solution

From the Solutions experience, we have the ability to create a new solution by clicking on the New Solution button.

A new tab will open where we can provide the Display Name, Publisher and Version of our solution. Once we have provided these details, we can click Save and Close.

Adding flow(s) to a Solution

From the Solutions experience, we can click on our newly created solution and navigate to its default view. A context-aware menu will appear that allows us to add New and Existing assets to our solution. Click on New – Flow to add a new flow to our solution.

A new tab will open that will take us to the flow design surface where we can construct our flow and add our related trigger and action(s). Once we are done editing our flow, we can press the Save button to save our flow.

 Once we have saved our flow, this flow will be part of our solution.

We can repeat these same steps to add subsequent flows to our solution.

Exporting our Solution

After validating our flows work in our test environment, we now want to promote it to our production environment. We can export our solution by finding it in our Solutions experience, clicking on the …, selecting Export and then clicking on As unmanaged.

Once we click As unmanaged, a zip file will be made available for us that we can download and store locally.

Importing our Solution

With our solution exported, we can now import it into another environment, such as a production environment. With our production environment selected from the environment picker, we can now choose to import our package by clicking on the Import button.

We now need to browse to select our solution package and then complete the wizard to load the solution.

Once we complete the import process, we will find our solution deployed within our new environment.

Configuring and Enabling our Solution

With our solution imported, there are still a couple of activities that we must perform: 

• For each flow that we have imported, we need to wire-up connections for our trigger(s) and action(s).

• By default, when new flows are imported, they will be in a disabled state since connections still need to be established. Upon establishing connection(s) and saving the flow, the flow will become activated.

Note: ​You cannot save changes to a flow that is activated. You need to de-activate it first either from the Solutions experience or the flow maker portal by turning the flow off.

Pre-requisites

The solutioning experience is available only online and for environment version 9.1.0.267 and later. To check your version, please go to …PowerApps admin center> Environments > select your environment > Details tab.

Future Investments

This is the initial release of solution support for PowerApps and Flow. This experience will be enhanced over time as new features are added and the process of deploying apps and flows is further streamlined.

Additional Resources

In this article we focused on including multiple flows within a solution. PowerApps can also be included in solutions as can a mix of powerapps and flows be included. Please check out Linh Tran’s post on the PowerApps’ blog regarding canvas apps in Solutions.

​

The post Solutions in Microsoft Flow appeared first on Microsoft Power Platform Blog.