A PowerApps Naming Convention Proposal
What’s in a name? Well, if you take the amount of effort that some brands go to in order to make themselves immediately recognisable, it would appear that names are rather important.
One of the things that has become apparent to me over the last 6 or so months as I have built my own apps, both at work and at home, is that having a strong and consistent naming convention is immensely useful to me. Additionally, having benefitted from being able to see the apps that other people produce, both by using products that people have loaded onto the PowerApps bank, and also by watching videos produced by a wide range of professionals it is apparent that there are a very wide range of naming conventions already in use.
In this article I’m going to explore why names are important, and make a proposal as to how we might choose to name our objects in the future.
Are Names Important?
Object names exist throughout PowerApps ranging from text boxes, dropdowns, buttons, variables and so on. They are unavoidable in any PowerApps solution, however simple. Here are some reasons why names are important:-
Maintenance
Have any of you inherited an excel spreadsheet produced by someone other than yourself? If you have then you’ll know how disorientating it is to try and fathom out the intentions of the creator. The apps that we produce to help run our businesses cannot be made in a way that makes them difficult to maintain or support. A strong, sensible, consistent naming convention will help with this.
Scalability and Efficiency
If you are producing apps at scale across your organisation there are patterns of behaviour that you may wish to reproduce over and over again. If you’ve created names that are so bespoke as to only ever relate to a specific app then this becomes much more difficult.
Development Efficiency
Linked in with maintenance the search function works like a dream when you have a good naming convention and allows developers to navigate around the app more easily. Below is a figure showing this in action.
Community Development
If as a community we are to create great solutions I believe that this will be on the back of creating really great reproduceable patterns of behaviour. However, if we don’t maintain a consistent manner of describing our objects our formulas will be less readable and less transferrable. As a result our collective rate of progress will be limited somewhat.
Is it easy?
It’s relatively easy to name objects in a consistent fashion, the difficulty is to get everybody in the community to do the same thing.
A Naming Convention Proposal
Ok let’s get serious. I’m going to offer a proposal for a naming convention and request that you all use the comments section below to see if it's agreeable to us all.
The proposal is as follows:-
Object | Category | Proposal | Alternatives |
Timer | Controls | tmrXXXX - Where XXXX is bespoke to your application |
|
Audio file | Controls | audXXXX |
|
Check Box | Controls | chkbxXXXX | check |
Button | Controls | btnXXXX | button |
Combo Box | Controls | cmbXXXX | combo |
Date Picker | Controls | datepkXXXX |
|
Radio | Controls | radioXXXX |
|
Slider | Controls | sliderXXXX | sldr |
Rating | Controls | ratingXXXX |
|
Import | Controls | importXXXX | imp |
Export | Controls | exportXXXX | exp |
Power BI Tile | Controls | pbiXXXX |
|
Attachments | Controls | attXXXX |
|
Collection | Data Sources | cnXXXX |
|
Data Entry Form | Forms | frmXXXX. Where the there is only one data entry form frmInput is preferred. |
|
Data Entry Card (the card that holds all the objects for a given field) | Forms | cardFieldName(where FieldName is the system name for the field) e.g. cardDateCreated | |
Datacard Value (the specific input that pushes data into the dataset) | Forms | dcvFieldName e.g. dcvDateCreated | |
Gallery | Gallery | glryXXXX | |
icon | Icons | icnXXXX | icon |
Image | Media | imgXXXX | |
Camera | Media | camXXXX | |
Barcode | Media | barcXXXX | brc |
Video | Media | vidXXXX | |
Microphone | Media | micXXXX | |
Add Picture Button | Media | addpicXXXX | |
Screen | Screen | scrnXXXX where XXXX is your choice | |
Opening screen | Screen | scrnLandingXXX | Alternative is scrnHome. ScrnLanding is preferred as the home screen may not be the same as a landing screen as this may just be a once only welcome. |
Label | Text Objects | lblXXXX | |
Text Input box | Text Objects | txtinpXXXX | |
Pen Input | Text Objects | peninpXXXX | |
HTMLText | Text Objects | lblhtmlXXXX | |
Rich Text Editor | Text Objects | lblrichXXXX | |
Global Variable | Variables | gvXXXX |
To see it in operation, take a look at the video below, If you are feeling keen download the standalone app from the PowerApps Bank here and review it on your own tenant.:-
That doesn’t sound too difficult. Is there a catch?
I wouldn’t say that there is a catch, but I would say that you may choose to leave your legacy apps alone, unless of course you are using one as a template for all other forms. If that is the case I think that it is worth the effort to go through a renaming exercise. Provided that you are methodical, and correct any issues as you go it is not a huge problem. If you do work with global variables, you must make sure that they are corrected everywhere they are used, and this is best done by interrogating using the file->variables->Global variables->definitions route and correcting it in every place. You will also need to correct it every place it is used by looking under ‘uses’.
Collections are quite a bit more difficult to rename as there is no means at this stage to verify where they are being used in the app (so good luck with that!).
I think I’ll stay as I am
Deciding to stay as you are is effectively a decision to accept whatever defaults are offered by PowerApps to you. In the simple example of creating 4 buttons you will end up with 4 objects called Button1, Button2, Button3 and Button4, but you won't have any idea as to what they do.
As your apps become more complex it is highly likely that you and your team will suffer the consequences at some point in the future. Troubleshooting an app with a naming convention, writing formulas and even seeing all your objects through search facility and the left hand side pane are significantly easier with a naming convention over the out of the box names. The figure below shows the search function in operation. With the exception of variables, every object with "bomb" in the name is easily identified.
I have no problem at all with the existence of default names, as these are designed to help new users to the platform, but as we push on our approach to developing apps as a community a shared way of working will be most beneficial. Try it – you might like it!
Comments below
We’re just at the start of a PowerApps revolution, and I think if you’ve landed here, you probably already know this. The specific naming convention chosen isn’t as important as simply having one and sticking to it, but if we all have the same one, then we will all be able to run much, much faster. Take a look at the example Minesweeper app by downloading it here and review it on your own tenant.
By all means provide comments on the proposal shown above, and suggest your own alternatives as maybe I’ve overlooked something along the way.