Showing results for 
Search instead for 
Did you mean: 

A PowerApps Naming Convention Proposal

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:-


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:-







tmrXXXX - Where XXXX is bespoke to your application


Audio file




Check Box








Combo Box




Date Picker
























Power BI Tile









Data Sources



Data Entry Form


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)


cardFieldName(where FieldName is the system name for the field)

e.g. cardDateCreated


Datacard Value (the specific input that pushes data into the dataset)


dcvFieldName e.g. dcvDateCreated






























Add Picture Button






scrnXXXX where XXXX is your choice


Opening screen



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.


Text Objects



Text Input box

Text Objects



Pen Input

Text Objects




Text Objects



Rich Text Editor

Text Objects



Global Variable




 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.



Hi, my preference is generally for 3 digit prefixes if possible.


Visual Basic mostly uses 3 digit prefixes for controls, see:


in particular for me:

Checkbox: chk (no need for the bx)

DatePicker: dtp

Radio: rdo



just a thought!

Thanks tchagan - this is brilliant feedback - just what I was after.  I'm quite tempted to see about creating a microsoft form and running a little survey to see if we can gain some collective consistency.  I do like the idea of 3 digits, I guess you'd have to run through all the possibilities to see if they make sense. 🙂

Hi @rorybi,


Very good subject! A good naming convention is indeed important and I also hear people structure with it.


He is my naming convention:

  1. Identifier for the control type
    1. I use short identifiers where possible (dd, cb, lbl, ti, btn, icn, gall,  ...)
  2. Identifier for the screen
  3. Identifier for the control / identifier for a panel / identifier for a gallery (gall)
    1. A panel is a subsection on a screen.
  4. Identifier for the control
    1. Unless this was also the case for (3).
  5. More detail
    1. I do not like ending with a number. I always try to give more detail when similar controls exists.

I use underscores to separate sections.




This is for a dropdown on the home screen containing weeks when using panels (it is on the first panel in this case). The dropdown has a label above it. 


Robot Happy Rick



I totally agree with this and frankly have been doing it since day one.  For those not doing it I can promise you that things are much easier when you can absolutely understand the notion of what you are dealing with right up front as you write and troubleshoot code.


One particular naming pattern I am starting to adopt to assist other in understanding my code is to delineate a collection, a record and a table so I prefix with col, rec and tbl.  For PowerApps it is really key to understand the differences and using a naming convention goes a long way to helping developers think through what they are doing.


Excelent initiative, one addition: if possible limit prefixes to 3 character. Important to have a consistent approach so not slider but sld. Based on the idea to consequently skip vowels until you have 3 characters. Of course the prefix should be unique.

Downside to this rigorous approach is that sometimes you end up with diffucult to read prefixes, then it time to make an exception Smiley Happy


In the old Visual Basic / VBA times this was a proven way to make your code easier to maintain.

Hi All,

Thanks for all your comments.  It seems like the 3 digit prefix is preferred and I think I will update the convention accordingly. 

@Rick72 it would be really helpful to see your approach in action as it would make for relatively long control names and therefore formulas that might be on the long side.  Nevertheless, I suspect if you had a really massive app this would be a great help.


Hi @rorybi,


I have added a screenshot below. As you can see, I keep the screen identifiers short because the names become indeed long then. I also have a documentation screen explaining which screen is used for what.


Robot Happy Rick



Thanks @Rick72 - you've probably gone for a Platinum level naming convention and I suspect if your methodology is followed through it would be very easy in the end.  I'm at this stage just trying to move us on to start with the 3 digit prefix (as opposed to the wild west of naming).  I'd still be a little wary of the length of the names in the formulas, but maybe it's a price worth paying for having a convention where you can find what you're looking for.  Thanks so much for sharing.


Hi @rorybi ,


I like the idea of naming standards, however there is one thing that we need to consider here.


As documented the accessibility checker flags up default Screen names.  


The important part of this document is the following:


Revise screen name Tip When a screen has a default name, which will be read out by screen readers when users navigate the app. Give the screen a name that describes what's on the screen or what it's used for. People who are blind, have low vision, or a reading disability rely on screen names to navigate using the screen reader.


screen reader read out the screen name. Hence I would suggest that the screen are called something like "Home Screen" or "Dashboard Screen" or maybe even just "Home" or "Dashboard" rather than something with a prefix and without spaces.

Hi @Pieter_Veenstra - I totally agree.  Actually, at the time of writing the article I wasn't fully au fait with how that would work from an accessibility point of view, but you are quite right.