This post should really be called “Our Top 100 Tips”, however we thought it would be fun to get together and agree our collective top 10 tips as a starting point for anybody wanting to flex their app development muscles using Microsoft Power Apps.
But first, a couple of comments:
Power Apps comes in several flavours, and these tips relate to Power Apps Canvas Apps, as Model Driven Apps (one of the other flavours) take care of a lot of these for you (although at the cost of interface design functionality).
Secondly, Microsoft are releasing updates to Power Apps at a very fast pace (sometimes whether you want them or not), so some of these tips are likely to be out of date almost as soon as this post hits our website. That said, we still reckon they’re pretty good tips.
So here goes…
1. Create Multiple Environments and Publish Often
It can be tempting to just go ahead and create your app in a development environment and publish it to users as you go. This works, but you’ll find yourself reliant upon Power Apps’ limited backup functionality, which currently only save a restorable copy of your app when you publish (i.e. not every time you press ‘Save’).
Whilst third-party backup tools that address this are available (we like AvePoint for this; our first tip is to create at least two environments for your solution: Development and Production (you might also consider creating a Sandbox Environment for ‘playing and experimenting’).
To help manage the DevOps process; Power Apps has built-in functionality to allow use to manage these staging environments using ‘Pipelines’
2. Use Power Apps Premium Licences
If you’re developing a business-critical app then you really need to look at using Power Apps Premium licences for your solution. Whilst they carry a small cost per user; they unlock several important features in your Power Platform environment that you will want to consider (three of these are discussed below).
3. Use Solutions to Manage Your App
Whilst you can dive straight in and create an app in Power Apps Studio; we strongly recommend that you use ‘Solutions’ as containers for your app, and its associated connections, data, flows etc. Solutions also form a critical part of the Dev Ops pipelines mention above; they do, however, require a Power Apps Premium licence, but are a must for critical apps.
4. Choose Your Data Sources Carefully
Many people first use Excel tables, or SharePoint Lists as data sources for their apps. That’s fine, but they do suffer from functional, and performance limitations, the most ‘feared’ of which are ‘Delegation Warnings’ (the little black and yellow warning triangles that start to show up when you’re manipulating data sources.
These innocuous warning triangles hide a rather show-stopping issue: if you have more than 2,000 records in your data table (it’s actually 500 by default, but you can increase it up to 2,000), and you get a delegation warning; your app simply won’t work as expected/planned. The warning basically means that the app can no longer rely upon the data source’s connector to manage large volumes of data and it will simply only ‘see’ the first 2,000 records when processing your query. No problem you might say, I will only need to return less than 2,000 records at a time. It’s not that simple – the data connector will actually ignore any data beyond the 2,000-record limit and won’t consider these records in a query.
For our production apps we use Microsoft Dataverse as our go to data source. Whilst it requires a Power Apps Premium licence; it overcomes the above, and many more challenges associated with less enterprise-grade sources. Dataverse also underpins Power Apps Model Driven apps if these are more to your liking.
5. Use Both Context and Global Variables
Power Apps basically has two types of variable that you can use in your app (not including Function Variables which are discussed below): Global and Context variables. As the name suggests the key difference is the scope of their visibility across your app.
Global variables, created using the ‘Set(varSomething, Value)’ syntax, are visible across all screens and components in your app. Context variables, set using the ‘UpdateContext({ctxSomething:Value})’ syntax, on the other hand are only visible on the screen on which they declared.
You might be tempted to use global variable for everything, however whilst they might seem a bit more cumbersome to work with, context variables allow you to separate variable logic to specific areas of your app, reducing the risk of unexpected cross-screen behaviour. We only use global variable when we need the value to be available app-wide.
6. Use the Camel Case Naming Convention
Not heard of it? That’s ok, it’s a bit nerdy, but very useful. Basically it means that, when naming variables, collections, components etc; you don’t use spaces, and capitalise each word except the first (e.g. lblFirstName, varDateOfBirth, ctxShowDetailsPanel). Whilst other ‘great’ naming conventions are available (e.g. Snake Case, Pacal Case); this one has become something of a standard in the world of modern app development.
It might sound like more hassle than it’s worth, however establishing a strong naming convention will make your code much easier to read, and will make searching for buried components a lot easier (e.g. trying to find a timer somewhere in your app – search for “tmr” and hey-presto, you’ll find all the timers, especially the hidden ones).
7. Standardise Your User Interface
Along with your data structure; your user interface is the most important factor in creating an app that is adopted (loved even) by your users. It should be designed to allow them to perform tasks, and access key information, with the minimum effort. We don’t ever start building an app without first gaining a deep understanding of its role in the client’s business, and how each category of user will interact with it.
Another key principle is to ensure consistency across all of your screens. Don’t change navigation techniques, and key information displays as screens change. In our apps, we use Custom Components (see next tip) to create reuseable components to create consistency across each app.
8. Custom Components
Whilst a bit ‘quirky’, custom components allow you to create reusable visual (or code) components that can be reused throughout your app. They can be created with properties and events to allow them to be tailored to behave in context, and to return output properties to the calling screen.
Another benefit of custom components is that they can be easily exported and imported into new apps, allowing you to reuse them across multiple projects. It’s our suite of these that has created the String House-Style that is familiar to all of our Power Apps clients.
9. Integrate Power Automate
Whilst not the subject of this post, don’t forget that Microsoft Power Automate can allow you to extend the reach of your Power App to countless use cases and external connections. There are too many uses for the Power Apps and Power Automate dream-team to list here, but we will typically use Power Automate to interact with the wider Microsoft 365 environment (SharePoint, OneDrive, Graph API etc), as well as third-party APIs such as Adobe, and B2B interactions.
As with other features discussed in this post, a Premium licence will be required to access Dataverse, and third-party APIs.
10. Use User-Defined Functions to Simplify App Logic
Whilst far from the ‘functions’ available in more traditional languages; Microsoft seem to be investing in this element of Power Apps due to its potential to improve the development experience. They need enabling as (at time of writing) they are still classed as ‘Experimental’ but, a bit like Custom Components (described above), they allow app/business logic to be made available app-wide to allow a degree of functional standardisation. We tend to use these to create common functions such as formatting an order number, creating descriptive elapsed time text, and creating dynamic user menus.
And there you have it; our top 10 tips to get you off to a good start with Microsoft Power Apps Canvas Apps. We had some fun choosing these, and I’m sure experienced Power Apps developers will have their own favourites. Please do let us know your thoughts in the comments.