Power Platform Community Forum Thread Details

Packaging (exporting) and reusing (importing) an App with connected Flows

Here's the big picture:

I created an App that allows users to request Leave events and routes those requests for Approval. This system consists of two SharePoint Lists (Leave Requests and Leave Approver Exceptions [for users whose Leave is approved by someone other than their manager, or users that don't have a manager, like students]), one App and three Flows (Leave Approval, Leave Cancel and Leave Update). The goal was to create this so that it could be deployed department-by-department, mainly because many departments will want specific customizations and our University has a proud history of letting departments do whatever the heck they want...er, I mean "encouraging academic freedom and diversity".

So, hurdle one in making this "deployable" was duplicating the SP Lists. After a bunch of trial and error, I was able to accomplish this (well about 80% of the way) using the PnP Provisioning tools to extract the lists to an XML provisioning template that can be applied to other sites to generate the lists. Note: Site Scripts is probably a better way to accomplish this, except these lists use custom content types, and apparently it's not possible to invoke a custom content type when provisioning a List using a Site Script. Also, I say 80% of the way because this method:

Does not duplicate the PowerApps-customized forms on the two lists (they have customized forms to prevent folks from editing items outside of the App)
Does not properly duplicate 3 "Calendar" type views on one of the lists (the views are created, but the "Calendar columns" values for Month/Week/Day View Title and the Sub Headings are not defined, so it doesn't render as a Calendar view until you go in and set those, which is a minor inconvenience)

In the end, not a perfect solution for duplicating the lists, but the best out of the methods available without third-party tools.

Now, hurdle two is to Export the App to create a package that can be imported. I went to the App, did the export bit and set everything in a way that made sense. That is, I set the App to generate a new instance (not update the existing one) and set all of the Flows to do the same, as well as the Connections. All went smoothly.

Next, I imported that package, gave the new App instance and the three new Flows appropriate names and they all got created properly, or at least as I expected. That is, the new App is still connected to the original lists. Since the new list instances are identical (the List Name and Column Names) to the original, I was able to just remove the original lists as Data Sources (which "broke" a bunch of stuff in the App) and add the new List instances (which "fixed" all the stuff that got "broke"). I anticipated this, so no big deal. I also know that in the Flows, I'll need to perform a similar switcheroo to connect them to the new List instance, which I've done before.

However, one issue that I wasn't anticipating, and I think will be a pain (not because it's difficult, but because I've found it to be finicky) is that (in the new App instance) the old Flows are still present as Data Sources and the formulas in new App that call those Flows are NOT updated. When I view the Details (from the PowerApps Apps page) and check the "Flows" tab, I see the three new Flows that were created. However, when I edit the App and view the Data Sources, the original Flows are still there.

Details > Flows:

App > Data sources:

Now, I know how to remove the old Flows and connect the new ones (which will involve updating the calls to them, so, not difficult, but time consuming), but I'm thinking that I may be doing this "the hard way". Is there another way to package/duplicate Apps with connected Flows? I know that using SP Lists would add some complication (ie: if we had access to CDS and used that as a data source, the relevant tables would - I believe - be re-created when importing the App), but I was hoping that since the App and Flows were packaged/generated together in what I thought was a coordinated way, they would already be properly linked.

I also spent a few days thinking through how to "paramaterize" the App in such a way that the Data sources and Flows could be "set" in some way (e.g.: as configuration variables in the App) or having the App prompt for them when the package is being imported or the App is launched the first time. If there is a way to do either of those, it's not well documented.

Categories:

Management

@v-xida-msft , thanks for your reply. In this case, I imported the package into the same environment, not a different one. If that known issue only applies to cross-environment deployments, then maybe there is a different cause here.

Also, I considered the Solutions option, but as it requires CDS and a Plan 2 PowerApps license, it is not an option for me. I currently have (since Monday of this week) a Plan 2 license for evaluation & testing purposes, but have not been cleared to use it for any production work at our University.

So, overall, it sounds like the "usual process" is going to involve pretty significant editing of the PowerApp to (1) update the data sources [which I expected] and (2) re-link to the newly-created Flows [which I was not expecting]. The Flows will also need to be updated to reference the new SharePoint lists.

This is a lot of work for something that's supposed to make things easier. Don't get me wrong, PowerApps & Flow are a huge leap ahead from SharePoint Designer Workflows and InfoPath Forms, but I can't be the only person frustrated by this. Hopefully PowerApps & Flow will mature to the point that it will be much easier to package & deploy solutions, especially those based on/interacting with SharePoint data.

Quick Links

Leaderboard > Power Apps - Power Apps Governance and Administering