- Posted by - Matthew Devaney
- on - November 30, 2021
- 11 Comments
The Power Apps Canvas App Coding Standards whitepaper was introduced by Microsoft back in 2018 to document best practices for coding canvas apps. A collaborative effort by Microsoft and members of the Power Apps community, it is among my favorite pieces of writing on Power Apps and I have put nearly all of its lessons into practice over the years.
Iâve decided to write my own take on the coding standards for two reasons. First, I want to share where my opinions differ on canvas apps development and my reasons for them. Second, despite good intentions the canvas app standards never became the âliving documentâ it was intended to be. Weâve not had an update to the standards since their initial publication.
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 NamesControl NamesVariable NamesCollection NamesDatasource 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 Type | Abbreviation |
Add Picture | pic |
Address Input | add |
Audio | aud |
Barcode Scanner | bar |
Button | btn |
Camera Control | cam |
Canvas | cvs |
Card | crd |
Charts | chr |
Check Box | chk |
Collection | col |
Container | con |
Combo Box | cmb |
Date Picker | dte |
Drop Down | drp |
Form | frm |
Gallery | gal |
Group | grp |
HTML Text | htm |
Icon | ico |
Image | img |
Label | lbl |
List Box | lst |
Map | map |
Microphone | mic |
Microsoft Stream | str |
PDF Viewer | |
Pen Input | pen |
Radio | rad |
Rating | rtg |
Rich Text Editor | rte |
Shapes | shp |
Slider | sld |
Table | tbl |
Text Input | txt |
Timer | tmr |
Toggle | tgl |
Video | vid |
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.
Scope | Declaration Method | Abbreviation |
Global | SET function | gbl |
Local | UPDATECONTEXT function | loc |
Function | WITH function | var |
Function | AS operator | tbl |
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 |
Text | Text |
Number | Num |
Date | Date |
Boolean | Bool |
Record | Record |
Table | Table |
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 Datasource | Abbreviation |
Dataverse | Dv |
SharePoint | Sp |
SQL | Sql |
Salesforce | Sf |
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)
Did You Enjoy This Article? đș
Subscribe to get new Power Apps articles sent to your inbox each week for FREE
Questions?
If you have any questions or feedback about Power Apps Canvas App Coding 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.
Matthew Devaney
- Power Apps
Power Apps Generate Row Numbers In A Collection
- Power Apps
Power Apps Tip: Hide The Navigation Bar In Play Mode
- Power Apps
Power Apps Hack To Style All Form Controls In Seconds
- Power Apps
Remove Duplicate Rows From A Power Apps Collection
- Power Apps
A Visual Guide To Power Platform Service Principal Setup
- Power Apps
Rename Variables In Power Apps With 1-Click
Subscribe
Connect with
Login
11 Comments
Oldest
Newest
Inline Feedbacks
View all comments
katie
8 months 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.
Reply
8 months 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
8 months ago
Reply to Adrian Colquhoun
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 8 months ago by Matthew Devaney
Reply
Juanma
8 months ago
thank you so much for share your experience, I find it usely. I love your post.
Reply
Sarah
8 months ago
Thanks for this, as a newbie to Power Apps and a citizen developer this is really useful.
Reply
James
8 months 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?
Reply
8 months 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
1 month 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.
Reply
Matthew Devaney
1 month ago
Reply to Christopher M
Christopher,
Youâre welcome. I plan to publish my own set of Power Apps coding standards in addition to this post about naming conventions. Make sure to subscribe and youâll get it once Iâm finished.
Reply
Christopher M
1 month 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
Reply
Matthew Devaney
1 month ago
Reply to Christopher M
Christopher,
The key/value pairings in a card are compromised of a label and an input control. Name them as you would any other control of this type.
DataCardKey1 -> lbl_Screen_FirstName
DataCardValue1 -> txt_Screen_FirstName
Reply
FAQs
What coding does Power Apps use? âș
Microsoft has announced the name of this language is Microsoft Power Fx.
Is coding required for Power Apps? âșYou can use PowerApps to create custom apps with Excel formulas â no coding required. Anybody familiar with the Microsoft ecosystem can create an app with PowerApp. You can use the tool to connect various data sources, both on-premises and in the cloud, using custom connectors or 400+ out-of-the-box connectors.
How do you code an app for power? âșPower Apps Source Code Tool - 10 Minute Overview - YouTube
What is the difference between canvas app and model driven app in Power Apps? âșThat level of integration with the Dataverse means Model-Driven Apps can be described as 'data-first'. They're far more rigid in their functionality than a Canvas App will be, with the UI (User Interface) components likely being selected from pre-made choices (although some customisation is still possible).
Is PowerApps functional programming? âșPower Fx is described as a general-purpose, strongly typed, declarative and functional programming language that helps users create canvas-based apps as opposed to model-based apps, as we explained earlier this year.
What language is used in Microsoft PowerApps? âșPower Apps uses the IETF BCP-47 language tag format.
Is PowerApps low-code or no code? âșPower Apps is the low-code development component of Microsoft's larger Power Platform, which also includes offerings for Business Intelligence and other functionality.
Is PowerApps no code? âșBuild apps without coding using Microsoft Power Apps
Empower teammates with all levels of experience to create the high-productivity apps your business needs with a rich set of tools.
Power Apps is Microsoft's low-code development platform that empowers developers, business users, and CRM Administrators to create custom native mobile and web applications by connecting to the cloud or on-premise data source. Power Apps leverage the Common Data Service (CDS).
Is PowerApps worth learning? âșPowerApps is a bit costly but worth it. It is a great no-code platform providing a good user experience. Also, it saves thousands of rupees which are usually required for creating apps using the traditional way.
Can you use CSS in PowerApps? âș
Conclusion. PowerApps is a low-code app which built for a simple system and expeditious implementation. So it will not contains fully-features to replace an web application and CSS is an missing now.
What is PowerApps code components? âșCode components are a type of solution component, which means they can be included in a solution file and imported into different environments. More information: Package and distribute extensions using solutions.
When should you not use PowerApps? âș- Hidden/Rising Costs. One of the biggest surprises companies encounter when they evaluate Microsoft PowerApps is that it isn't a âfreeâ enterprise product. ...
- Absence of Smartphone Features. ...
- Lack of Security Control. ...
- Steep Learning Curve. ...
- Sub-Standard Offline Capability. ...
- Limited Integration.
There are two main types of Power Apps: Canvas apps and Model-driven apps. Previously, Power Apps Portals would have fallen under this category. Microsoft have since released Power Pages, a standalone product that has evolved from the functionality of Power Apps Portals.
What coding does power automate use? âșPower Automate for desktop enables you to automate complex scenarios using scripts in VBScript, JavaScript, PowerShell, and Python.
Is PowerApps hard to learn? âșWhat's more, PowerApps is generally quite easy to learn. You can use it to swiftly take charge of your destiny as long as you make the correct decisions when it comes to structuring.
What is power automate built on? âșPower Automate is built on the Common Data Service Platform and allows you to connect to the Microsoft suite of software. This suite includes Office 365, Dynamics 365, Azure, Microsoft Teams, and more. âMicrosoft Power Platform is an inclusive technology.
Is PowerApps a developer? âșThe Power Apps Developer Plan gives you a free development environment to build and test with Power Apps, Power Automate, and Microsoft Dataverse. The plan enables you to: Create apps and flows without writing code, with full-featured Power Apps and Power Automate development tools.