In many coding languages, having a set of standards, principles & practices is key. Standards are important to maintain quality, make bug fixing easier and in some cases, stay compliant with national or international legislation. Power Apps standards follows the trend of other languages and tools, whereby a useful set of standards help developers and makers stay consistent.
As with any standards, they’re hugely subjective and down to personal or organisational preference. On that note, this article will share a handful of my approaches to standards & practices when working with Power Apps. They aren’t right or wrong, simply my opinions that I thought I’d share in case they can help others.
Naming conventions are hugely important when it comes to Power Apps standards. They’re a fundamental aspect of writing high-quality and sustainable code, no matter what the language or programme. Here’s a couple of reasons why:
1- Maintainability; the Power Platform doesn’t stand still, it’s constantly evolving. As it does, developers or makers often need to revisit and modify existing code, or extend with additional functionality. When the names of controls, variables and collections are meaningful, we can quickly identify functionality, making it much easier to extend or update without breaking anything.
2- Easier troubleshooting; the same reasons as maintaining & extending, well defined naming conventions can help quickly debug and fix errors with your Power Apps.
3- Readability; having a consistent set of naming conventions helps anyone collaborating on the development to understand the logic and purpose of controls and code.
It might be difficult to have EVERYONE in your organisation follow EVERY SINGLE standard; the key is to be consistent and logical. If one person prefixes a collection with ‘col’, don’t introduce a different prefix elsewhere in the same app. If you inherit an app with standards you think could be better, use the search/find/replace functionality to bulk change.
As a guideline, Microsoft released a white paper a few years ago to cover naming conventions and other standards. I largely follow their examples so will regurgitate them here. Newer controls have been added since that paper was released (such as containers), where’ll I’ll introduce a prefix or standard myself or with the team I work with.
Speaking of containers. I try not to prefix them with ‘cnt’ because, well, that’s only one letter away from being rather naughty isn’t it.
Variables
Whilst I follow a common approach to naming controls, with variables I likely differ from most. I’ve never been a massive fan of ‘loc’ for context variables or ‘gbl’ for globals (which I sometimes see as glb too). No idea why I’ve never got on with those prefixes and they’re perfectly fine for others – again this is all subjective. I just don’t find them to my liking, I wanted something more consistent and easier (for me) to identify and write.
My approach is therefore to prefix global variables with gv, context variables with cv & temporary variables with tv. In my head, they’re each a type of variable so the v is representative of that. The letter beforehand tells me what type of variable it is.
// Context variable example, using cv as the prefix
UpdateContext({cvLoggedOnUserEmail: Office365Users.MyProfileV2().mail});
// Global variable example, using gv as the prefix
Set(
gvLoggedOnUserEmail,
Office365Users.MyProfileV2().mail
);
// Temporary variable example, using tv as the prefix
With(
{tvUserEmail: Office365Users.MyProfileV2().mail},
If(
tvUserEmail = "craig.white@Platformsofpower.com",
"Do something",
"Do something else"
)
)
Naming screens
Whilst variables and controls will have a prefix and usually follow pascal or camel case naming conventions, screen names are different. To quote directly from the Power Apps coding standards white paper:
“Screen names should reflect the purpose of the screen, so that it’s easier to navigate through complex
apps in PowerApps Studio.
What’s less obvious is that screen names are read aloud by screen readers, which are needed for users who have vision accessibility needs. Therefore, it’s imperative that you use plain language to name your screens, and that the names include spaces and no abbreviations. Also, we recommend that you end the name with the word “Screen,” so that the context is understood when the name is announced.“
We still see a lot of ‘scnScreenName’ or ‘Home’, ignoring that some users will struggle if they’re using screen readers. This standard is less subjective and more of a JFDI, as there’s less wriggle room here.
“That’s ok, the app is only for a few people and none of them have any vision accessibility issues”
But they might at some point??? Who knows what the future holds. Likewise, what if a new starter joins with accessibility needs? Build your apps to include EVERYONE, not just the majority. So screen names should follow that guidance, examples of good ones will be something like:
Home Screen
Request Screen
Approval Screen
With accessibility in mind, that leads nicely onto the next tip.
Popups / modals / dialogue
A typical design we see is having a label being shown over the top of content, with additional text or buttons for users to interact with. Unfortunately, these aren’t recommended in Power Apps. Popups, modals, dialogue boxes – whatever you want to call them, are not compatible with screen reader technologies:
Have I done this before? Yes, lots of times because I didn’t know about the above. Now I do, so I’ll try to build my apps to be future proof for anyone with accessibility needs. There’s actually a 4th suggestion to the above too; you don’t necessarily need a separate screen for each dialog. You could have a single screen that shows or hides content based on the previous screen the user is on (shout out to Sancho Harker for introducing me to this concept). That’s something I’ve baked into more and more apps recently and will be its own article very soon, along with other accessibility topics as per this Microsoft article.
There’s SOOOOOOO much content on the interwebs for making dialogs/popups in Power Apps. Unfortunately, almost all of them neglect to mention that it’s not an accessible technique. Please make sure your apps are accessible for users now and in future.
Screen transitions
When I started building with canvas apps in 2016, I loved screen transitions. I felt like I’d unearthed some cool hack that made users go “WOW, how did you do that?”. Obviously I’d reply with “it took me ages to code that in, hope you like it!”. Over the years though, my opinion has changed to the point where I no longer use screen transitions at all.
For me developing on my rapid wifi, screen transitions work really well and give the desired effect. But for users on slower internet speeds or poor cellular connections, screen transitions are likely to be painfully slow and tedious. My default these days is ScreenTransition.None:
We can make this easier still, by simply not specifying a screen transition in the Power Fx. This will automatically default to no screen transition:
// Navigate to the home screen
Navigate('Home Screen')
Comment your code
Another one of the less subjective Power Apps standards and more of a JFDI. Plain and simple. You might know what your code is doing, but who else will?
Also, will the future ‘you’ remember all the logic perfectly? There’s no guarantees. Even then, comments need to be descriptive to help not just you, but others too. I try not to simply describe the action…
// Set gvUserEmail global variable
Set(
gvUserEmail,
Office365Users.MyProfileV2().mail
)
… but provide some additional context for future reference:
// Set gvUserEmail global variable.
// Output of variable used to filter gllResults gallery on Review Screen
Set(
gvUserEmail,
Office365Users.MyProfileV2().mail
)
I covered a quick way to add comment blocks in Power Fx as one of my first articles on this blog. You can even feed Copilot blocks of code and ask it to comment it for you. You literally have no excuse.
Something I will recommend here is don’t leave all your commenting until the end of your build. It’s going to be tough to remember every single control and property where you’ve added some Power Fx. I usually build and comment as I go:
Format your code (well, most of the time)
Power Apps Standards are all about making things easy to read and maintain. That’s a lot harder if your Power Fx is left unformatted. Luckily in the formula bar, there’s a button that does this for us:
Where we have multiple commands in a single block, this will do a great job in separating out onto individual lines. This also makes it easier to add comments to, so that’s a bonus.
The only frustration with this is how it formats anything with numbers. Formatting an RGBA value is an example, here is my unformatted RGBA:
Here’s what happens when I hit format text:
I stick to using HEX values now, less hassle 😂
But that quirk aside, the format text option is super useful and one I’ll use everywhere to make my code more readable for myself and others.
Experimental / preview features
A Power Apps standard/best practice that’s a bit more generic – don’t use experimental or preview features in apps that will be shared with other users.
You can see from this Microsoft article that experimental features are definitely not recommended for production apps, as they can change very quickly. The article says you can use preview features with more confidence, however in my experience this isn’t always the case. We also see a lot of queries on the forums relating to preview features, with errors/problems disappearing when they use a control or technique that’s fully released.
Unfortunately, some features are preview for a very long time. This can be frustrating if you want to use them, so I recommend keeping an eye on this area of the Power Apps forum. Use your judgement and ask on the forums for educated help. For example, the formula-level error management preview feature has been around since the Triassic Period, but rarely have I experienced it cause issues. Other preview features aren’t always so lucky.
Routinely check App Checker
In Power Apps Studio, you can find the App Checker in the top right hand corner:
This will automatically detect certain issues with your app and show a red circle next to this icon for our attention. Sometimes though, the red circle doesn’t show, so don’t simply assume your app is perfect.
I’ve lost count how many times I’ve edited someone else’s app to find a barrage of issues or recommendations under App Checker. It seems to be habit to leave this until then end of a development, which then makes it a lot easier to forget about.
Much like commenting your code, make it a habit to keep checking this throughout the lifecycle of your build. Implement any recommendations you can to resolve issues around performance & accessibility.
Use the Code Review tool
This is a go-to standard for me, as it keeps me in check to ensure I’m building a well rounded, performant app. We talk these days about pipelines, XRM Toolbox, PAC CLI and other tools as part of the kitbag for a Power Platform developer. The Code Review tool should absolutely be sitting alongside.
If you’re unsure what the Power Apps Code Review tool is, please check out this article.
Keep it DRY
Regular visitors to this blog will know I don’t like WET code, I like to keep it DRY where possible. This is a must for Power Apps standards.
WET – Write Everything Twice
DRY – Don’t Repeat Yourself
In Power Apps, this can take a couple of different forms.
1- Reusable components; Let’s say your app has a gallery acting as a navigation menu. The gallery is copied onto each screen so users can select an item no matter where they are. What we’ve done here is write our menu functionality multiple times. If anything changes, we’ll need to edit the gallery on each screen, one at a time.
This is where Power Apps components are so valuable, as it enables us to write once, use lots of times. Updates are done in one place and instantly cascaded to wherever the component is being referenced. You can build in-app components which can only be referenced by a single app, or a component library that can be used by many apps in the same environment.
2- Reusable code; Let’s say you have a block of Power Fx that first needs to run when the app starts. The same block of code needs to run a second time after the user has performed specific actions. It’s easy to duplicate the blocks of code twice, but can be a nightmare to keep both updated & in sync. Will you always remember to update all the places where the duplicate code exists? I speak from experience that it’s easy to forget something and maintaining two blocks of the same code is a pain.
An easy technique I live by now is using a hidden button to perform logic. I can then ‘call’ this button from other behavioural properties (such as OnVisible, OnSelect etc), Power Apps then thinks the user has selected the button and so runs the relevant Power Fx. This technique – and other good ones are documented on this Microsoft Learn article.
Thanks for reading. These are some of the key standards/practices I tend to do on auto-pilot now. What standards and best practice do you follow when building canvas apps? Let me know in the comments below.
If you liked this article and want to receive more helpful tips about the Power Platform every week, don’t forget to subscribe or follow me on socials 😊
Great post sir thank you. Love the WET & DRY analogy. I’m going to introduce this in our daily workings.
Thanks for the feedback, Gavin. Really appreciated. Yeah the WET/DRY analogy is one of my favourites, I heard it a few years back from someone I worked with at the time & it’s stuck since. It can apply to so many scenarios whether writing code or creating a document – don’t duplicate effort. Good luck with weaving it into your daily workings
with your variables, how do you name ‘Constant’ Variables
(ie. those created in the App.Formulas property)
which cannot have their definition changed for the existance of the app.
Hi Cameron, it’s a good question & one I wrestled with during my Named Formulas article a few weeks ago! I originally thought of using nv, standing for Named Variables, but they’re called Named Formulas, so I went with nf as my prefix in the end, ie nfTheming, nfUserProfile etc.