Microsoft has introduced a couple of solution-specific features to assist in Power Platform development that we have been excited to review and implement. They are Child Flows and Environment Variables. These features help to address some of the major pain points in Power Platform deployment and change management. They must be used within the context of solutions and environments, which we’ll expand on below. In this article, we’ll review these features as well as how to develop solutions for the Application Lifecycle Management environment structure.

 

Child Flows

Prior to releasing the Child Flow feature, the only available method to call a Power Automate flow from another flow was to use the HTTP trigger. Utilizing this trigger required a bit more technical understanding of web service calls and data structures to implement and so may have been out of reach for the more non-developer-oriented flow authors. The HTTP trigger also became a premium trigger so the licensing cost would need to be considered in the implementation. With the release of the Child Flow feature, the ability to call another flow became supported out of the box. Additionally, if you create your flow from within a solution, you will now have an additional Child Flow action that will allow you to call your child flow.

 

Environment Variables

If you have ever exported and imported a Power Automate flow or Power App form for use between two different SharePoint sites, then you have felt the pain of having to reset every SharePoint connection reference within the flow. If there are many SharePoint actions in the flow, this method is very cumbersome and also prone to error. With Environment Variables, the SharePoint data connection can be configured in one location and referenced in the flow. When importing to a different environment, the change to the SharePoint site can be made in one location which helps simplify the deployment process.

As a side note, it is possible to use the method of modifying the exported zip file to change the SharePoint site and list GUID references before importing on.

Solutions and Environments

In order to leverage the two features above, there are two requirements: implementation of a solution and multiple environments for solution deployment.

Solutions are containers that can hold any number of components like Power Apps, Power Automate flows, Dataverse tables, Environmental Variables, as well as many other component types. In order to deploy a solution, multiple environments are required to represent Dev, Stage, and Production. The creation of a solution in a Dev environment would automatically be set as an unmanaged solution. It can then be exported as unmanaged (for deployment to a different Dev environment) or managed (for deployment to a Stage or Prod environment). One of the key factors here is that if you delete an unmanaged solution, it only deletes the container, and all the components remain in the environment. If you delete a managed solution, then all components in that solution will be removed (if no dependencies have been added).

Note, it is not possible to create a duplicate copy of any solution inside the same environment. There is a Clone feature in the Solution context menu, but it does not create a duplicate version of your solution as the name might imply. Instead, the Clone feature rolls up all related patches to the base solution and creates a new version.

 

Application Lifecycle Management Tips

Once you have created a solution in your Dev environment and are ready for deployment to Stage/Production, here are some tips to avoid potential snags along the way:

  1. Managed Solution objects cannot be modified directly. However, they can be modified through an unmanaged solution. Every environment has a Default Solution where all objects are available.
  2. When modifying an object through an unmanaged solution, it adds an unmanaged layer to the object. Any future managed solution updates will not update these objects because the update process is unable to delete unmanaged layers. Changes in an updated solution will not be applied unless the unmanaged layer is deleted
  3. Currently, to avoid adding unmanaged layers as much as possible, one option that has worked for us is to make all environment-related changes in the Dev environment before exporting the solution. This includes updating Environment Variables to match Stage/Prod before exporting. Then only minimal changes should be needed after exporting into Stage/Production. In the Dev environment, this will require changing these Stage/Prod values back to the Dev values afterward to continue development.
  4. Power App forms get a new URL upon deployment to a new environment through a solution. To address this with environment variables, you can do a double export/import. First import brings in solution with all environment variables updated EXCEPT the Power App URLs. Once the new URLs are documented, they can be added to the Dev solution for a second import/export to bring in the updated Power App URLs to the Stage/Prod environment.
  5. Microsoft Word Connections don’t work with environment variables configured on the Document Library. The method above of changing the library before export will work to make sure these values don’t need to be adjusted after export.

 

Additional Notes

  • It is highly recommended to start development within a Solution from the start. Inside a solution, Connection References and Power App triggered workflows will be created for you. If you create these outside of a solution, extra steps need to be taken in order to import them into the Solution correctly.
  • It is not a hard requirement to have multiple environments to utilize the Solution and Child Flow configuration. If there is only one environment available and the Child Flow structure is useful, then an unmanaged Solution could be created in that environment in order to implement Child Flows. Keep in mind that once you have created a Solution to hold your Power Automate flows, it cannot be managed the same way as flows outside a solution. For example, a simple flow export/import will no longer work to restore one of your flows to a prior version. There is no way to import an individual flow directly into a solution. We believe that the best option to version flows in a solution is to export the whole solution as unmanaged. Theoretically, importing this unmanaged solution should restore all components (including the flows) to that point in time. This would impact other components as well since we are importing the entire solution.
  • Any per-app or per-flow premium licensing would need to be replicated for each of the environments you wish to create like Dev, Stage, and Production.

 

Get expert help with Power Apps and other business process automation solutions

Learn more about Compass365’s Power Platform Consulting Services. Our team of experts can help you modernize processes and solve tough challenges quickly and cost-effectively.

Reach out directly to Cathy Ashbaugh, cashbaugh@compass365.com to arrange for a complimentary consultation.

Compass365, a Microsoft Gold Partner, delivers SharePoint, Microsoft Teams, and Power Platform solutions that help IT and Business leaders improve the way their organizations operate and how their employees work.