In this article, we take a look at Flow deployment issues when it comes deploying multiple PowerApps applications. The issues are encountered when you have the following setup.
- You have multiple applications within the same environment. For instance in the same environment, you have a PowerApp called AppDEV, AppQA, AppUAT and AppPROD
- You have applications connected to their respective SQL Servers.
- You have a separate Flow for each App and they are named as FlowDEV, FlowQA, FlowUAT, and FlowPROD
- Each Flow will use a different connection such as SQLConnectionDEV, SQLConnectionQA, SQLConnectionUAT and SQLConnectionPROD.
To deploy the application, please follow procedure listed below:
- Export the application and on the Export package screen under Related Resource for the app, for each resource and for Import Setup option, select either Update or Create as New option.
- Import the application and on the Import package screen under Related Resource for the app, for each resource and for the Import Setup option, select either Update or Create as New option.
Ideal deployment scenario,
Export AppDEV app and import it into AppQA app. The connections for AppDEV and AppQA are pointing to their respective connections including Flow.
Deployment 1.
When we export the app for the first time, we select the Update option for the SQL Connector and Create as New for the Flow, since the Flow doesn’t exist in QA.
Expected Behavior
1. AppQA should be connected to SQLConnectionQA
2. FlowQA should be connected to SQLConnectionQA.
Actual Behavior
1. AppQA is connected to SQLConnectionQA
2. FlowQA is connected to SQLConnectionQA.
So this is good, as everything is as expected. Alright, follow along as new requirements have come up and require a new deployment.
Deployment 2.
Now assume that we have the environment setup as shown below.
1. AppDEV and FlowDEV connected to SQLConnectionDEV
2. AppQA and FlowQA connected to SQLConnectionQA.
When we export the application, our gut instinct is that since SQL Connector and Flow both exists as QA we need not to select “Create as New” for the Flow. So we select Update option during Export and Import of the Application.
Expected Behavior
1. AppQA should be connected to SQLConnectionQA
2. FlowQA should be connected to SQLConnectionQA.
Actual Behavior
1. AppQA is connected to SQLConnectionQA
2. FlowQA is now renamed to FlowDEV and is to SQLConnectionQA.
Our environment now looks like as follows:
1. AppDEV and FlowDEV connected to SQLConnectionDEV
2. AppQA and FlowDEV connected to SQLConnectionQA.
To recap, if you didn’t notice, we now have two Flows by the same name called FlowDEV on pointing to SQLConnectionDEV and another pointing to SQLConnectionQA but by just looking at the name we don’t know which Flow is which.
The issues now start to compound.
Deployment 3.
On the Import screen, on the Import Setup option, click on the Update option. When presented with the Flow to select you will be presented with two flows by the same name FlowDEV. At this point you do not know which Flow is pointing to SQLConnectionQA. Accidentally, you clicked on the wrong Flow and then you deploy.
The issues happen because you do not know which Flow is getting used by your application. If you delete the wrong flow then the PowerApp starts misbehaving. Again if more people create additional flows and it becomes a huge mess trying to chase down the bug.
Solution
The solution to this problem we have come up with is to during the Import process always select “Create as New” option and then follow a naming convention. When you have multiple flows created by this method, you can delete the older flows.
The naming convention
Follow the naming convention if you are doing a deployment on 2019-05-12 at 10:47.
<Environment>_NameoftheFlow_20190512_1047.
<Environment> is either DEV, QA, UAT or PROD.
What are the benefits of using this naming convention?
The different parts of the name provide different benefits and they are as follows:
Environment – When multiple flow is helps determine the Flow is targeting which environment. However, always verify on Flow details page regarding which connecting string is being used.
Name of Flow – Provide a distinct name that will be unique across different applications. This will provide us some hints with the purpose of the Flow.
Current Date – Add date formatted as 20190512 (YYYYMMDD). It helps to identify when the Flow was created and when it is safe to delete the Flow. For instance, if a newer Flow exists for the same environment then a cleanup can be performed.
Current Time – Add current time formatted as 1053 (HHmm). It helps to distinguish Flows that were created the same day.
You can check flows that were created older than the most recent one and delete them. So far this approach has worked for us and you can suggest if you have an alternate way of deploying PowerApps with Flows in this kind of setup.
What are the disadvantages of this approach?
The Flow execution history will be lost if you are concerned with that. However, if everything was successful then after certain period of time probably you do not care about the execution runs.
It also has an administration overhead as you have to remember stuff and it is definitely not DevOps friendly approach.
