Have you ever wondered why your Power Automate Cloud Flows in your solution are turned off when you deploy your solution to UAT or PROD using automated deployments through Azure DevOps? And are you tired of manually activating your cloud flows and linking them to active connections every time you deploy via Azure DevOps — a task you definitely shouldn't do because you actually should use managed solutions. Then this blog series is for you.
I'll explain why these issues happens and how you can resolve them by using the deployment settings file, thereby creating a healthy Application Lifecycle Management (ALM) for your Power Platform and Dynamics 365 (CRM) solutions. Achieving a healthy ALM is the ultimate goal of this series.
To keep this topic from becoming too long, I have decided to split it into three parts. This is the first post regarding the topic of using the deployment settings file in Azure DevOps when deploying Power Platform solutions.
Introduction
If you have previously performed a manual deployment to a UAT or PROD environment, where you exported your solution from the development environment and then imported it into the target environment, and if your solution included environment variables and connection references, you may have found that you are asked to manually populate these.
Therefore, add values to your environment variables that are tailored to the specific environment you are deploying to and ensure that your connection references are linked to the relevant active connections in the target environment.
This is the standard procedure for manual deployment to downstream environments, also called the environment centric approach.
However, with fully automated Continuous Integration / Continuous Delivery (CI/CD) scenarios using pipelines and repositories in Azure DevOps, also called the source-code centric approach, this manual option to populate environment variables and connection references is not possible. Therefore, in order to enable a fully automated deployment we need to make sure to automate this task and pre-populate our connection reference and environment variable information specific to the target environment we want to deploy to. For a better understanding of the differences between environment-centric and source code-centric approaches, you can read Benedikt Bergmann's insightful blog post here: Environment vs. Source Code-Centric ALM Approach.
Fortunately, there is an automated solution to pre-populate. We can use the deployment settings file (DSF) in Azure DevOps to solve this challenge and ensure that the cloud flows in our solutions remain active and functional in the target environments. I often find that the issues with the cloud flows and connection references in the target environments is a reason why many still deploy unmanaged solutions, as it allows them to manually tweak these components each time they deploy to UAT or PROD. This is not the recommended approach and instead, solutions should be deployed as managed solutions, which is an ALM best practice from Microsoft. Microsoft has also recently launched a new feature that allows admins to block all unmanaged customizations in target environments such as UAT and PROD, which is a clear signal that managed solutions should be used for deployment. It also indicates that Microsoft is increasingly focusing on this area, which is amazing for Power Platform developers that really prioritize healthy ALM.
So to summarize, the DSF can therefore help ensure that your cloud flows in your solutions do not turn off in target environments and bring you a step closer to using managed solutions during deployment through Azure DevOps.
Before I delve into how to use the DSF in the release pipeline (also called the Continuous Delivery pipeline) in Azure DevOps, I will in this first blog post provide a explanation of the differences between a connector, a connection and a connection reference - since this is a crucial part of it. In the second blog post, I will explain what actually happens when we are not using the DSF to pre-populate connection references and environment variables and explain what we ultimately aim to achieve with the DSF and why it is important to use. In the third and last blog post, I will provide a step-by-step guide on how to actually use the DSF in your Azure DevOps release pipeline.
What is the differences between a connector, a connection and a connection reference?
Before I explain what happens when you do not use a DSF in your release pipeline in Azure DevOps, it's important to fully understand what a connection reference entails and how it differs from a connector and a connection. I often find that it is typically the handling and lack of understanding of these three concepts that cause cloud flows in a solution to be turned off when deployed to a target environment. Although they may seem very similar, there are actually significant differences that you need to be aware of. I often encounter confusion between these concepts in my work as a consultant, so here is a brief explanation.
A connector allows Power Apps and Power Automate (and also Azure Logic Apps) to access data and interact with other cloud services like SharePoint, SQL Server, Outlook, Dropbox, Workday, SAP etc. Currently, there are over 1,200 certified connectors available. Connectors are one of the features that make the Power Platform unique, as both pro and citizen developers do not need to build APIs for specific services from scratch. Instead, we as developers can quickly use these certified and out-of-the-box connectors to interact and connect with other services and data sources. If you want to interact with a service that doesn't already exist as a connector, you have the option to create a custom connector for that service, but that’s a completely different topic.
Your Power Platform objects, like a cloud flow, are not linked directly to a connector. Instead, your cloud flow connects to a connector through a connection. For example, if you want your cloud flow to create a file in SharePoint (which is the connector), this happens through a connection. When you add the SharePoint action to create a file in your cloud flow, it will check if there is already an active SharePoint connection in your environment. If there is, it will use that connection. If not, it will automatically create one by logging into SharePoint using your account.
When it comes to handling connections and ALM, it is important to remember that connections are environment-specific, meaning they cannot be added to solutions and, therefore, cannot be deployed to target environments such as UAT and PROD. This is were connection references come into play.
In contrast to a connection which is environment-specific, a connection reference is solution-specific. Connection references can therefore be created and added to a solution and deployed to the target environment. There's nothing complex or extraordinary about a connection reference; it is simply a component in your solution that contains a reference to a specific connection. It should be viewed as a bridge between your solution-aware flows (and in rare cases, solution-aware canvas apps) and the connections in the specific environment used in your flows within your solution. A connection reference can be created manually in your solution, but often it will be created automatically when you create a new connection from the cloud flow that you have in your solution.
In the screenshot below, you can see that, unlike the previous screenshot where it says "My connections" (indicating that the SharePoint action is directly linked to a connection because the flow is outside of a solution), it now says "Connection references." This is because the flow is inside a solution.
A good rule of thumb is to have only one connection reference per connection in your solution. For example if your solution includes four cloud flows that use the Microsoft 365 Outlook connector, you should have one connection reference for Outlook, used by these four cloud flows. This will make it a lot easier for you to have a clean solution and also make it easier when you deploy your solutions and when using the DSF in Azure DevOps.
For a more detailed explanation of these concepts, you can also read the following blog post by Benedikt Bergmann: Connections and Connection References Explained. Benedikt has created a great visualization/model that showcases the relationships between connectors, connections and connection references.
I also prefer to read the official Microsoft documentation about connection references: Microsoft Power Apps Documentation.
Next steps 👉
I hope you liked the first part and that it gave you an understanding of the importance of using the deployment settings file in your release pipeline in Azure DevOps when deploying your solutions. Additionally, I hope you have gained clarity on the difference between a connector, a connection and a connection reference, as the handling of these is ultimately what the DSF helps to resolve.
In the next blog post of this series (part 2), we will take a deeper look into this topic and explore what actually happens when we do not use DSF in our release pipeline, and also what we ultimately aim to achieve. I have also included some visual examples to simplify the understanding 😄
Here is a link: https://www.serhatyildiran.com/why-use-deploymentsettingsfile-part2/
Please add a comment below or reach out to me through LinkedIn, if you have any questions.
Join the conversation