The Good

Being able to develop OOB low code/no code solutions within the Microsoft framework has been a hallmark of the platform for some time. As of recent history, we had InfoPath and SharePoint Designer workflows within SharePoint to develop robust solutions solving complex business needs with little to no code. These solutions were easy to implement and cost effective due to rapid development.

The new low code/no code solution to solve business needs in now Power Platform. Here we can use Power Apps forms along with Power Automate Flows that will work not only on SharePoint, but on any number of data sources including DataVerse tables, SQL Server, and a whole host of non-Microsoft data sources to utilize as a back end. An extremely powerful set of tools for robust solutions and plenty of extensibility.

As any of us who worked in the InfoPath/SharePoint designer world know, creating these solutions were relatively easy…but moving these solutions to another SharePoint instance was not. As many of us worked with some form of development, test, and production environments, it was extremely difficult to move a solution from one to the next. This type of issue was taken up by Microsoft in Power Platform by allowing us to export everything created, either individually or as a whole underneath a solution, to be imported back into either another Power Platform environment (be it Sandbox, Production or Trial) or even into another tenant. Finally, a true way to test within a dev environment and implement a solution in a production environment easily! Well…maybe not quite so easy. There are some tricks to moving things from environment to environment and we will review some of the issues to look out for and think about while developing your solution so you understand how to move a solution and some useful pre-planning that will save you a lot of time and energy when doing so.

The Bad

There are some definite concerns that should be heeded when attempting to develop a solution on Power Platform with the intention of exporting/importing the solution to another environment.

Attachments in Power Apps

When developing Power Apps, you will notice a nice feature is the ability to import media. This can be high resolution images, videos and more. When Power Apps imports these files in it will add them as attachments.

The issue is there is a size limit when both exporting and importing Power Apps solutions or individual Power Apps of 25 MB. The main reason for this is when a Power Platform asset is exported it is just code…a combination of xml, asset files, json, etc. so it can be put back together again upon import. Usually, 25 MB would be more than enough (even for an extremely large solution) since it is only text ultimately that is being exported. When you have multiple large attachments that are media it can easily take this space up. The resulting error you will see is below:

The solution is to put all assets into a data repository (such as a SharePoint document library) which can then be referenced or import the attachment into your new environment post import. The only way to get rid of this error is to ultimately delete the attachment that is too large.

The Ugly

Before I go on here, I would like to reiterate that being able to export/import solutions into other Power Platform environment as well as other tenants all together is a wonderful thing, and I am sure as time goes on Microsoft will most certainly address these issues. For now, though there is a problem with Power Automate flows which I will break down into two different types and the issues that occur.

Flows created directly within Power Automate

It is important to make a distinction between two separate types of flows at this point. Below I will talk about any Flow that is associated with a Power App (has steps in it that are associated with Power Apps). The flows in this section are any flow that is not associated with a Power App.

When importing flows into a different Power App environment within the same tenant you will notice that things are smooth as all URL’s or associated assets are already within the tenant and will naturally be associated again upon import. The trouble begins when a Power Automate flow is imported into another tenant. While you will be prompted to add/update connectors upon import the issue lies with steps that have hardcoded elements within them or assets a flow is referencing do not exist in the environment. See screenshots below…

Flow with Steps in source tenant

Same flow after importing into destination tenant

At first glance it shows the List Name as a guide since it does not exist in the destination tenant since the site address also does not exist. The problem can stretch further though. Even though the ID field shows as being correct it too is not hooked up correctly.

The only way to resolve these issues with flows is to reconfigure each property in a step making sure to click on it. It is best to check each step and each property in each step and retest your flow to make sure that it works correctly.

Flows with PowerApps steps

Flows that were created via Power Automate in the PowerApps menu or flows that have PowerApps steps added have a different issue then other Power Automate flows. As of the writing of this blog these flows are not able to be imported into another environment. This means that if you create flows with Power Apps steps within them you will need to recreate them in your destination enviornment. Microsoft has been apprised of this issue. Note the error screen shots below that occur upon import for two separate Power Automate flows that have Power Apps steps within them.

Attempting to import a solution with Power Automate Flows with PowerApps Step connectors

Error Download Details:

[{"SolutionValidationResultType":"Error","Message":"The following solution cannot be imported: ManufacturingFlows. Some dependencies are missing. The missing dependencies are : <MissingDependencies><MissingDependency><Required key=\"0\" type=\"connectionreference\" displayName=\"new_sharedsharepointonline_beb14\" solution=\"Active\" id.connectionreferencelogicalname=\"new_sharedsharepointonline_beb14\" /><Dependent key=\"1\" type=\"29\" displayName=\"Upload Cover\" id=\"{650c7f86-2d96-eb11-b1ac-000d3a4f1f8c}\" /></MissingDependency><MissingDependency><Required key=\"0\" type=\"connectionreference\" displayName=\"new_sharedsharepointonline_beb14\" solution=\"Active\" id.connectionreferencelogicalname=\"new_sharedsharepointonline_beb14\" /><Dependent key=\"2\" type=\"29\" displayName=\"Upload Video\" id=\"{c90dfab6-2196-eb11-b1ac-000d3a4f1f8c}\" /></MissingDependency></MissingDependencies> , ProductUpdatesOnly : False","ErrorCode":-2147188707,"AdditionalInfo":null}]

Conclusion

The ability to create robust Power Platform solutions that can be exported/imported is a huge plus for the Microsoft cloud ecosystem and will surely drive platform adoption. With the noted exceptions above there are considerations when developing these solutions specifically when migrating between tenants as some things will need to be fixed upon import. I would assume that most, if not all, of these issues will be fixed in the near future but prudent planning should be done in the near term. If you want to talk about this topic further, please feel free to contact us today!