Power Apps Standards: Naming Conventions

Power Apps Standards: Naming Conventions
Table Of Contents:
• Screen NamesControl NamesVariable NamesCollection NamesDatasource Table Names




Screen Names

A screen name should clearly describe its purpose in 2-3 words ending with word “Screen.”  Use proper-case.   A screen-reader will speak the screen name to visually-impaired users when the screen loads.

Good ExamplesBad ExamplesBad Reason
Appointments ScreenAppointmentsMissing the word ‘Screen’
Order Form ScreenOrderFormScreenNot friendly to a screen reader
Collect Signature ScreenscrCollectSignatureNot friendly to a screen reader




Control Names

A control name should show the control-type, the purpose and the screen.  Use camel-case and underscores for spacing.  For example, the control named txt_OrderForm_FirstName is a text input that captures first name on the app’s Order Form Screen. 

Good ExamplesBad ExamplesBad Reason
drp_NewEmployee_DepartmentdrpDepartmentNewEmployeeNo spacing
btn_OrderForm_Submitbtn_Submit_OrderFormWrong order
gal_Home_Appointmentsgly_Home AppointmentsNon-standard control prefix



A list of standard control prefixes can be found below.

Control Prefix
3D Object 3do
Add Picture pic
Address Input add
Audio aud
Barcode Scanner bar
Button btn
Camera Control cam
Canvas cvs
Card dtc
Charts chr
Check Box chk
Collection col
Container con
Combo Box cmb
Component cmp
Date Picker dte
Drop Down drp
Export exp
Form frm
Gallery gal
Group grp
HTML Text htm
Icon ico
Image img
Import imp
Label lbl
List Box lst
Map map
Measuring Camera mcm
Microphone mic
Microsoft Stream str
PDF Viewer pdf
Pen Input pen
Power BI Tile pbi
Radio rad
Rating rtg
Rich Text Editor rte
Shapes shp
Slider sld
Table tbl
Text Input txt
Timer tmr
Toggle tgl
Video vid




Variable Names

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

Good ExamplesBad ExamplesBad Reason
gblUserCurrentUserCurrentNo scope
locPacksInBoxQuantityLoc_Packs_In_Box_QuantityImproper capitalization and spacing
LocIsLoadinglocBoolLoadingDo not use data types in variable names
varWorkdaysDuringVacationvarWorkdaysNot descriptive enough




Collection Names

A collection name should contain the original datasource and describe its purpose. Use camel-case with no spaces between each word.  For example, the collection colDvInvoices is a collection of invoices from Dataverse.


Good ExamplesBad ExamplesBad Reason
colSpEmployeescolEmployeesNo datasource
colDvSalesLeadscoldv_salesleadsImproper capitalization and spacing
colNavigationMenuNavigationMenuDo no use data types in variable names



A standard list of datasource abbreviations can be found below:

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




Datasource Table Names

A datasource created by the developer should have 1-3 words to describe its purpose.  Use the singluar form of the word and proper-case.  Be as concise and clear about the purpose of the datasource as possible.

Good ExamplesBad ExamplesBad Reason
EmployeeEmpAbbreviation instead of full word
Construction ProjectsProjectsToo general, what type of projects?
Repair OrdersRepairOrdersNo spacing, plural





Questions?

If you have any questions about Power Apps Standards: Naming Conventions 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.

Subscribe
Notify of
guest
9 Comments
Oldest
Newest
Inline Feedbacks
View all comments
David Wyatt
David Wyatt
3 months ago

Interesting read thank you, though little confused around your thoughts on data types in variable naming. As you say it should (which I totally agree with) but then ‘locBoolLoading’ is bad because it includes data type?

David Wyatt
David Wyatt
3 months ago

Thanks for clarity, interesting choice not too. I like a structure of scope-type-description as easier for intellisense (as I can filter the variables down as I type)

Reiner Knudsen
Reiner Knudsen
3 months ago

I saw some MS document somewhere and found it very confusing – and hard to use. These instructions are much better. I will add this to my ressource collection 🙂

Felix Gieseke
Felix Gieseke
1 month ago

Hi Matthew, great work on the guide!
I’d like to propose a minor improvement for the control naming. I would add the control type as suffix. Then you have the order of the name parts by their relevance for most use cases.
A common scenario is to have a data field “FirstName”. Then on the form you have an input control for that field together with a label. If you use OrderForm_FirstName_txt and OrderForm_FirstName_lbl as control names you see on the first glance, that those two belong together. Especially if you order the controls on the screen/form by name.

Hjalmar Otto Fjøsne
Hjalmar Otto Fjøsne
1 month ago

Excellent guide, and site for that matter!

I’ve tried using the official whitepaper for some time and find it very useful. I notice that you have introduced an underscore after the prefix for control names, which is not the case in the official whitepaper, can you share the reasoning behind this convention?

Hjalmar Otto Fjøsne
Hjalmar Otto Fjøsne
10 days ago

I see your point on visibility, but I’m a bit worried that introducing another convention (snake_case combined with camelCase and or PascalCase) adds more complexity than what its worth. Another thing is that pascal, camel, snake (and so on) case are familiar convention patterns pro developers are familiar with, and that pro developers in fusion teams may find it a bit too unconventional 🙂