PowerApps and Flow Deployment Issues

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.

PowerApps From A DevOps Perspective

In this post, I would like to talk about PowerApps from a DevOps perspective. When we think about DevOps we think about Source Control, Continuous Integration, Automation, Configuration Management etc. Let’s take a look into it.

No Source Control for PowerApps

When you are developing with PowerApps, there is no way to do Source Control. There are no source files. The only artifact you can version control is the .zip file that you can export. The application that you create/edit in the browser is continuously updated and whenever you feel like it is ready for publishing then you make that version of the application available to users in your organization. Lack of version control causes problems when you cannot track down which version of the application caused a particular bug. The only way to guarantee no bugs is by doing a thorough testing of the application.

Multiple Environments Beware

Creating a separate Dev, Test, UAT and Production environment is quite common for DevOps practices. In PowerApps, you can create separate environments in PowerApps but it comes with its own problems. For instance, in order to create and administer environments you need Plan 2 License in PowerApps. This is not a big deal since you can manage with one license. If you are creating application that uses On-Premises Data Gateway then only applications from the Default Environment can connect to the Gateway. Yeah! if you thought that was a bummer. Then you are right. Well all hope is not lost, if you really need it then you have to create a support ticket with Microsoft. Another limitation with multiple environments is that you cannot create as many environments as you like. Because you can only create two production environments. Another bummer. If you wanted Test, UAT and Production environment then you are toast. You will have to request another user license and then you would be able to create it. In PowerApps, having multiple environments creates more issues in my opinion from a DevOps perspective. It is not as seamless as one would come to expect from a traditional DevOps practice. If you are creating Model Driven apps only then it makes sense to create multiple environments. If you are creating only Canvas Driven apps then just create different apps with – DEV, TEST, UAT and PROD suffixes. Having multiple apps for different purposes creates it own issues as detailed below.

CI/CD Pipeline

In PowerApps, you don’t have to build your code. Any change you make to the application is live for you to test it. In that way it is very productive. To publish the application you just click on the publish button and it is live. But what if you screw an update, then you have an option of going back to a previous version of the application. The workflow of getting the application to end-users all the way to production is not seamless. Since we create different app for DEV,TEST,UAT we had to export and import every time we had to propagate a change to these apps. For one of the applications we built it was quite a lot of work every time we exported and imported into another application-dev/test/prod. For instance, we had to ensure that all the connections were pointing to environment specific connection strings, data going in accurately, perform manual checks, create a new flow every time.

Configuration Management

Well there is none. You cannot manage configuration of your PowerApps application in one place. For example, you can put app settings inside web.config file in a typical asp.net web application. In asp.net when you change environments then you can just update web.config. If you want to persist your app settings then it is better to put them inside a SQL table if you are utilizing On-Premises databases. In other words, store your app settings into an external persistent store.

Collaboration

It is very common to collaborate with brilliant team mates on different projects. If you are using any modern source control system then you can easily collaborate with Team members and work on features simultaneously. In PowerApps, only one developer can work on the application at given point of time. Good luck building your next ERP front end! One of the selling points of PowerApps is that it is very good for building quick small single purpose application that a single developer can churn out in days. But not good when you want to build a large application.

Since we are on the topic of collaboration let me add it here. If you developing application for an enterprise and think people are going to use it, then please don’t use your own personal account to develop the application. Because the user who creates the application becomes the owner of the application and guess what, you cannot change the owner of the application later on. If you are an ops guy then you want to have that ownership of the application. Please utilize a service account to develop PowerApps application.

That’s all I have for today and if you would like to share anything regarding PowerApps please let me know in the comment below.

5 Takeaways for Building PowerApps Application

In this post, I would like to share some of the pitfalls we encountered while developing an enterprise grade PowerApps Application.

First some background about the application. The key components of the application comprised of an on-premises SQL Server, Enterprise Data Gateway, Microsoft Flow and Windows Service. The SQL Server database consisted of enterprise ERP data and hence entities in this database had lots of columns just like a typical ERP system. The application we built was PowerApps Canvas application where you have more control over the look and feel of the application. We were surprised by how much you can customize the look of the application and make it look enterprizey [see I made up a new word].

Limit the number of controls
There are couple of reasons why you want to limit controls that are present on a page and in the whole application.

1. For performance reasons, in PowerApps Canvas driven apps, if you are adding lots of controls on a given page then performance of the application degrades. We saw performance of dropdowns controls and calendar controls decrease. Dropdown would appear after a delay and calendar popup would show after a delay.

2. In PowerApps if you add any control in the application then you can access that control from anywhere unlike Windows Forms page where you can only access controls that are present on a given page. Oh! that’s powerful you might say and that is why it is called PowerApps. As you add more controls to PowerApps, it becomes difficult to keep track of all the controls and soon you will run out of creative and unique names to provide for your controls.

3. After some point when you have lots of controls, you will forget control names and make mistakes while trying to reference the right control. Why did that popup didn’t disappear when it was supposed to.

Limit the logic you put into the Functions bar
One of the SOLID principles is Separation of Concerns and when you go against it then it bites you where it hurts the most. In PowerApps, presentation layer is meant for displaying and Microsoft Flow is for handling business logic processing. The Function bar at the top is so powerful that you can accomplish a whole lot with so many functions at your disposal. So no wonder we added a ton of business logic into it and to a point that lines of code increased to 1000 lines. No kidding. In hindsight, it is always easy to point the mistake and bang on the head that it was so obvious but everyday it is not. Let’s go through the issues with putting lot of lines of code into that tiny function bar at the top. People familiar with Excel will be able to relate to this.

1. Every single time to view code you have to expand the function bar.

2. Endless scrolling of numerous lines of code.

3. As lines of code increases, error messages looked like some ancient Egyptian symbols. We were spending hours debugging the error message. Luckily we knew how to comment code :) and narrow down the issues.

4. Smallest mistake or a syntax issue can take up hours to resolve it because the error message don’t point to the the current line of code. Oh and did I tell you that there are no line numbers for the code you write in that function bar.

5. Function bar freezes when there are many lines of code. Even few characters of text can take few seconds to appear. When you try to comment out a section it takes a while to take effect.

6. Bonus! There is no source control for that code. So if you broke something then good luck. Like a good programmer you should always use source control for any type of code. If you had lot of logic associated with a button and you clicked on Associated Flow with this button then oops you just lost all that logic. Please put code into source control.

Limit the number of columns and records you display
PowerApps is not meant to create the front end of an ERP system and it should not be used for such purposes. PowerApps shines when you build an application that fulfils that last mile gap. As there are more columns on a given page, the page becomes slower to respond and UX is not the best when a user has to scroll horizontally or vertically to view the full picture.

Put application settings into external table

In PowerApps, there is no App.Config or Web.Config file where one can put application settings and change them. So it is important that you store app settings into an external table. If you hard code some key into Application then when you try to export and import PowerApps to create a new application then you will have to edit that key again. Try to do that at multiple places and this process become quickly inefficient. Again this is basic 101 if you a developer.

Do not fear Flow because of Licensing issues

Early on we wanted to be cost effective and hence avoided using Flow. The moment we found ourselves stuck with having to debug 1000 lines of code again and again we decided to give Flow a chance. What we learnt after reading the docs is that for our purposes, the Flow quota allotted for per user per month were plenty. If you have Office 365 license then you have 2000 executions allowed per user per month and it is aggregated at the tenant level. As soon as we resorted to Flow and extracted key business logic into SQL Server stored procedure, we were back to application stability.

So that’s all I have to share this Monday late night. If you have your learnings regarding PowerApps please share in the comments below.