Power Apps Naming Conventions For Canvas Apps

Power Apps  Naming Conventions For Canvas Apps

It is important to have a consistent set of naming conventions for all of the objects in a Power Apps canvas app. By following the same patterns all Power Apps developers can more quickly understand each others apps and introduce less bugs when working on them. These are my own opinions on naming conventions in Power Apps canvas apps for screens, controls, variables, collections and data sources.

Table Of Contents:
Screen Names
Control Names
Variable Names
Collection Names
Datasource Names




Screen Names

A screen name should describe its purpose in 1-2 words suffixed by the word ‘Screen’. Use proper-case.

Home Screen



Discussion

It is important that each screen’s purpose is described in plain-language because screen-readers will speak this text to visually-impaired users when the screen loads. If the screen has more than one-purpose, consider distributing the functionality across multiple screens.

Good Examples

  • Appointments Screen
  • Order Form Screen
  • Collect Signature Screen


Bad Examples

  • Appointments [missing the word ‘Screen’]
  • OrderFormScreen [not friendly to a screen reader]




Control Names

A control name should indicate the control-type, which screen is found on and its purpose. Use camel-case separated each piece of information with an underscore. This example shows a text input, found on the Order Form Screen whose purpose is to capture the first name of the person placing the order.

txt_OrderForm_FirstName



Discussion

When typing a formula in the editor we often want to reference another control. We don’t often remember the control’s name and rely on auto-complete to find it. First we write the control type to narrow the list of possible matches and then we type the screen name to refine the search further. The result is a list of all controls on the screen with a matching type.

The full list of control name abbreviations can be found below:

Control TypeAbbreviation
Add Picturepic
Address Inputadd
Audioaud
Barcode Scannerbar
Buttonbtn
Camera Controlcam
Canvascvs
Cardcrd
Chartschr
Check Boxchk
Collectioncol
Containercon
Combo Boxcmb
Date Pickerdte
Drop Downdrp
Formfrm
Gallerygal
Groupgrp
HTML Texthtm
Iconico
Imageimg
Labellbl
List Boxlst
Mapmap
Microphonemic
Microsoft Streamstr
PDF Viewerpdf
Pen Inputpen
Radiorad
Ratingrtg
Rich Text Editorrte
Shapesshp
Slidersld
Tabletbl
Text Inputtxt
Timertmr
Toggletgl
Videovid



Good Examples

  • drp_NewEmployee_Department
  • btn_OrderForm_Submit
  • gal_Home_Appointments


Bad Examples

  • drpNewEmployeeDepartment (no spacing)
  • btn_Submit_OrderForm (wrong order)
  • gly_Home_Appointments (control abbreviation not found in standard list)




Variable Names

A variable name should show the scope of the variable, the data type and its purpose. Use camel-case with no spaces between each word. This example is a global variable which holds the current user’s email address.

gblTextUserEmailCurrent



Discussion

The scope of a variable restricts where it can be used in the app – every screen in the app (global), one specific screen (local) or within a specific code-block (function). A prefix indicating the variable’s scope helps us quickly understand where it is available.

ScopeDeclaration MethodAbbreviation
GlobalSET functiongbl
LocalUPDATECONTEXT functionloc
FunctionWITH functionvar
FunctionAS operatortbl



Variables can only hold a single, consistent data-type throughout the app. If a variable is set as a text data type in one code block and set as a number data type elsewhere the app will show an error the next time its opened in studio mode. This type of error can be incredibly frustrating to track down in a large app. For this reason it is important to know what data type a variable holds.

Data Type Abbreviation
TextText
NumberNum
DateDate
BooleanBool
RecordRecord
TableTable


Good Examples

  • gblRecordUserCurrent
  • locBoolBlockUserInput
  • varNumWorkdaysBetween

Bad Examples

  • gblUserCurrent (no data type)
  • Loc_BlockUserInput (improper capitalization and spacing)
  • WorkdaysBetween (no scope or data type)




Collection Names

A collection name should communicate the original datasource of the table and its purpose. Use camel-case with no spaces between each word.

colDvInvoices



Discussion

Collection data can be generated from one of two places – a persistent table from a connected datasource or a temporary table created inside the app. Persistent tables must have data periodically read/written back to them. Understanding where the data originally came from makes this task easier.

Original DatasourceAbbreviation
DataverseDv
SharePointSp
SQLSql
SalesforceSf
None (created in-app)(none)




Good Examples

  • colSpEmployees
  • colDvSalesLeads
  • colNavigationMenu


Bad Examples

  • colEmployees (missing datasource)
  • NavigationMenu (missing prefix)




Datasource Names

A datasource name should describe its purpose. There is no word limit but keep it short. Use proper-case.

Sales Leads



Discussion

In many cases a developer has no choice over the datasource name and must use what is already in place. There may also be constraints imposed by the datasource itself. Whenever possible be as concise and clear about the purpose of the datasource as possible.



Good Examples

  • Employees
  • Construction Projects
  • Repair Orders

Bad Examples

  • Emp (abbreviation instead of full word)
  • Projects (too general, what type of projects)
  • RepairOrders (no spacing, hard to read)





Questions?

If you have any questions or feedback about Power Apps Canvas Naming Conventions For Canvas Apps please leave a message in the comments section below. You can post using your email address and are not required to create an account to join the discussion.

Matthew Devaney

Subscribe
Notify of
guest

11 Comments
Oldest
Newest
Inline Feedbacks
View all comments
katie
katie
2 years ago

Thanks for putting this together! I didn’t realize how camel casing in screen names impacted app accessibility. I have been using parts of these naming conventions but I think I can definitely save myself from some future headaches by adding type to my variables as well source to my collections. Really helpful breakdown.

Adrian Colquhoun
2 years ago

Thanks Mathew.

I like your rationale and approach to control naming, but wonder why you don’t extend this approach to naming variables?

For example gblRecordUserCurrent would become gbl_Record_UserCurrent and locBoolBlockUserInput would be loc_Bool_BlockUserInput.

I think this might make for more readable code blocks for citizen developers and expert reviewers?

As an side, there is no relation between the naming of the variable and its actual scope and data type (unless someone what’s to write some AI smarts to check this in the background). So consistent naming is a good first step but citizen developers need to be consistent about how and where they define their variables or there is still scope for errors.

Thoughts?

Matthew Devaney
Matthew Devaney
2 years ago

Hello Adrian,

I debated using underscores in variable names for awhile. My thought is: I like how underscores make control names visually distinct from variable names. In the blink of an eye you can tell whether something is a control or variable without having to read any of the words. When you look at a block of code its immediately apparent.

This is definitely an opinion of mine, and I’m open to debate, but I’m sure you can agree there’s no right or wrong way to do things here, just good or better. I think many people will read your comment think “yeah, Adrian’s got it right here, not Matt” and that’s OK. Its healthy to have a debate.

As for scoping variables, I agree its up to the citizen dev to be consistent, let alone use use local variables. When I do a code-review I always check the variables overview screen in Power Apps to see if I mistyped a variable prefix. Comes in super-handy.

Thank you for sharing your detailed opinion and contributing to the discussion.

Last edited 2 years ago by Matthew Devaney
Juanma
Juanma
2 years ago

thank you so much for share your experience, I find it usely. I love your post.

Sarah
Sarah
2 years ago

Thanks for this, as a newbie to Power Apps and a citizen developer this is really useful.

James
James
2 years ago

I notice that out of the box, the cards and their subsidiary controls get some pretty unhelpful names – not even based on the data-field bound to the datacard.

How often do people have a Grand Renaming of a form?

Matt Harding
2 years ago

I agree with most of this, in fact I adopt almost all of these. I do tend to call Collections col_Name though, keeping the underscore consistent with control names like lbl_Name.

One more thing worth noting is that control names must be unique over the whole app, so for example if you add the same label to every page to show the time for example, you should use the initials of the page in the label name.

For example the Home Screen label could be lbl_Time_HS and the same label on the Form Screen would be lbl_Time_FS.

Christopher M
Christopher M
1 year ago

I’ve recently begun learning to create apps using the MS PA platform and your posts stand head and shoulders above everything on the internet.

After following one of your post/tutorials, I was very curious if you had a system for your naming conventions (appears as you might), and here it is. This type of system is essential for clarity, especially when one references so many varied elements.

Thank you for sharing this, and all of your helpful posts. The PowerApps world would be 95% less great without you.

Christopher M
Christopher M
1 year ago

Cards provide key/value pairs upon creation

default key name: DataCardKey1
default value name: DataCardValue1

I didn’t see them covered in your blog post.

Any naming convention suggestions for them or things that make sense to avoid?

My first thought was this convention:
abrev_Screen_CardTitle

which provides (for a card that captures a column named ‘FirstName’):

key_Home_FirstName
val_Home_FirstName