Power Platform Build: Three Mistakes You Might be Making in Your Power Apps

I'm not the best Power Apps developer out there: over the past three years, I've built some apps that make me cringe when I look at how they were built. However, making mistakes is often the best way to learn and I want to share my lessons on building better apps right out of the gate.

Mistake 1: You aren't documenting your Power Apps application

Just because Power Apps is technically "low-code" doesn't mean the traditional rules of development are out the window. An important concept of development is documentation: documenting your use case/app ensures that someone else could take over app ownership and have enough information to understand how the app works. It also helps you understand what you built: in six months when you look back at your undocumented app, you might struggle to understand what you were trying to achieve!

Here are two ways of adding documentation to your Power App: using code comments and creating a documentation screen.

Comments help describe what the code is doing and provide additional context.

An app screen dedicated to documentation ensures that any new app owner can easily understand how the app is structured. You can also link to documents that provide additional use case/app information.

Mistake 2: You were too focused on creating a functioning app that you haven't considered the user experience

User experience is just as important as building a functioning app. A working app with a bad user experience leads to frustrated end users, avoidable mistakes, and low adoption of the app. When building apps, I try to regularly assess the user experience by asking myself, "If I was an end user opening this app for the first time, would I be able to successfully use this app?" Below are some UX tips for your Power App:

Use visual guides to assist the user through the app

Some examples of helpful visual guides:

• The tooltip property on controls allows the app maker to provide a description of the control that appears when the user hovers over it.

• The display mode property on controls, like buttons, visually hints to the user that the button is currently not clickable.

Include error handling and status messages to avoid mistakes

A user needs to know when their actions were successful or when something has failed. We can use the Notify function to display a pop-up message to an end user, whether you are confirming a successful action, warning a user about an action, or prompting them with an error message.

You can also use the Validate function to check if what you are trying to submit is valid for the data source. It assess constraints like whether a column requires a value, how long a string can be, how high/low a number can be, how early/late a date can be, etc.

Then, the Errors function can be used to retrieve error information for previous changes to a data source for issues like data conflict, insufficient permissions, missing required fields, etc.

Follow accessibility guidelines so all users can benefit from your app

Creating accessible apps should be a priority for all Power Apps makers. Within the Power Apps maker studio, you can use the "Accessibility Checker" feature to identify ways to make your app more accessible.

Microsoft has put together an accessibility standards and guidelines whitepaper that you can download from here . You can also reference our docs articles on accessible canvas apps .

Mistake 3: You are making Power Apps work harder than it has to

I could write a full blog on optimizing Power Apps performance, but I want to point out some quick performance tips to fix some common mistakes/issues.

Try to use delegable functions as much as possible

Delegation is a confusing but important concept to grasp in Power Apps development. When running through a formula, Power Apps prefers to hand off the processing of data to your data source. When the data source does the processing, it only returns the data you need. However, not all Power Apps functions are delegable, which forces Power Apps to bring the data to the app for local processing. For these non-delegable functions, Power Apps gives the ol' "college try" but only processes 500 records by default. This limit can be increased up to 2,000 records via the app's settings, however don't be surprised if performance is a bit slower. The list of delegable/non-delegable functions can be found in our documentation .

Minimize the number of calls to your data sources

Avoid calling your data source multiple times, especially when the data has not changed.

As you can see below, I have a Maintenance Request table and need to store title, description, severity, and contact's email as their own variables. However, using this approach is repetitive, because it makes four separate calls to the same data source for the same record.

Instead, the approach below makes one call to the data source for the record and stores the full record as a variable: a nice feature about Power Apps variables. Then, the following four lines reference the first variable for the individual pieces of the record it needs.

The same concept applies when pulling and displaying the app user's information. Rather than calling the Office 365 Users connector three separate times to get three pieces of information (like below), you should store the user's full profile information in one variable and reference pieces of the variable in the textboxes.

Avoid repetitive code

Repetitive code can occur in several ways and tends to negatively impact performance. One example of this is writing "If" statements that repeat the same code. In the screenshot below, the icon displayed is dynamic based on the number of stars next to it. For example, the happiness rating is currently at 2 stars, therefore the icon shown is "Emoji Frown". While this technically works, you can see that the code is repetitive, with "RatingHappy.Value = X" being replicated 5 times.

We can streamline this "If" statement by using the Switch function instead. The next screenshot shows how the same capability can be accomplished using less code.

Another example of repetitive code is using the same formula in multiple places. In the example below, I have five buttons to select, but the bottom three should be disabled if the app user doesn't have any direct reports. Instead of repeating the code on the display mode property for all three buttons, I should either store the output of the code as a variable and reference that variable or put the code on one button and reference the display mode of that button on the other two.

Finally, just because you've made one of these mistakes in a previously-built app doesn't mean you can't improve upon it. Some of my best learning experiences came from digging up old apps from my Power Apps graveyard and revamping them.

Happy building, Power Apps makers!