Power Apps Naming Conventions: The Complete Guide (With Examples)

If you’ve ever opened someone else’s Power Apps canvas app and had absolutely no idea what Label5, TextInput3, or Variable2 is supposed to do — you already know why naming conventions matter.

And honestly, I’ve been there too. I’ve come back to my own apps after a few weeks and spent 20 minutes figuring out what I built. That’s wasted time. Good naming conventions fix that.

In this tutorial, I’ll walk you through how to properly name everything in a Power Apps canvas app — screens, controls, variables, collections, and data sources. I’ll also show you real examples of naming conventions in Power Apps.

What Are Power Apps Naming Conventions and Why Do They Matter?

Power Apps naming conventions are standardized rules for naming controls, variables, collections, screens, and other elements within your application. Think of them as a universal language that allows any developer—including your future self—to instantly understand what each element does and how it functions within the app.

Here’s what happens when you skip them:

• You spend more time debugging because you can’t tell which button belongs to which screen
• Other developers (or your future self) have no idea what a control does just by looking at it
• Formulas become harder to read and maintain
• It’s nearly impossible to scale the app or hand it off to a teammate

And here’s what happens when you follow them:

• Your app tree is clean and readable from top to bottom
• Formulas are self-explanatory — Set(gblTextUserEmail, User().Email) tells you everything
• New team members can pick up the app and understand it quickly
• Debugging takes minutes instead of hours

Microsoft’s own canvas app coding standards document says it best: the main point is to be consistent. It doesn’t have to be perfect — it just has to be consistent.

The General Rules for Power Apps Naming

Before we get into each element, here are the general rules you should follow for Power Apps naming conventions:

Rule 1: Always Use Descriptive Names

The most critical rule is simple: names should describe what the element is or does. Avoid generic default names like “Button1” or “Label3” at all costs.

Bad Examples:

• Button1
• TextInput2
• Gallery3
• Label4

Good Examples:

• btnSubmitForm
• txtEmployeeName
• galProductCatalog
• lblWelcomeMessage

Rule 2: Implement Consistent Prefixes

Using three-letter prefixes for controls makes your code instantly readable. When you see “btn,” you immediately know it’s a button. When you see “gal,” you know it’s a gallery. This pattern recognition accelerates development and troubleshooting.

Rule 3: Use Camel Case Notation

Use camelCase for controls, variables, and collections (no spaces, capitalize each new word).

Format: prefixDescriptiveNameHere

Examples:

• btnSaveRecord
• txtUserEmailAddress
• galFilteredEmployees
• lblTotalAmount

• Use plain language with spaces for screen names
• Avoid abbreviations unless they’re obvious to everyone on the team
• No special characters like @, #, or & in names
• No reserved words — don’t name a variable Filter or Sort
• Keep names under 25 characters where possible — this prevents truncation in the formula bar

Rule 4: Maintain Consistency Throughout Your App

Choose a naming convention and stick with it religiously. Mixing different conventions creates confusion and undermines the entire purpose of having standards.

Rule 5: Balance Description with Brevity

Names should be descriptive but not verbose. Aim for clarity in 2-4 words maximum.

• Too Long: btnClickThisButtonToSubmitTheFormAndSaveAllDataToDatabase
• Just Right: btnSubmitForm
• Too Short: btn1

Check out How to Add Comments in Power Apps Canvas App?

Power Apps Screen Names

Power Apps Screens are the easiest place to start because the rule is simple: name them in plain English, with a space, and end with the word “Screen”.

Why plain English with spaces? Because Power Apps screen names are read aloud by screen readers for accessibility. If you name your screen BrwsScr, a screen reader will try to pronounce that out loud, which is a terrible experience for someone with vision needs.

Here’s the format to follow:

[Purpose] Screen

Good examples:

• Home Screen
• Browse Screen
• Details Screen
• Edit Screen
• New Record Screen
• Settings Screen

What to avoid:

❌ Incorrect	✅ Correct	Why
BrowseScr	Browse Screen	Don’t abbreviate
DetailsScreen	Details Screen	Include the space
editScreen	Edit Screen	Use proper capitalization
Browse	Browse Screen	Always end with “Screen”

One more tip: keep it to 1–3 words. If your screen name is Customer Order History Approval Review Screen, that’s a sign the screen itself is doing too much.

But you can also use the Prefix naming such as, srcHome, srcLogin, srcSettings, etc.

Check out PowerApps Navigate to Another Screen

Power Apps Control Names

This is where most people either get it right or make a mess. Controls are your buttons, labels, text inputs, galleries, dropdowns — everything you see on the canvas.

The naming format I recommend is:

[prefix][PurposeAndContext]

Where prefix is a short 2–4 letter code that identifies the control type, and PurposeAndContext describes what it does and where it lives.

Here’s a full list of the standard prefixes for classic and modern Power Apps controls:

Control	Prefix	Example
Button	btn	btnSubmitForm
Label	lbl	lblEmployeeName
Text Input	txt	txtFirstName
Gallery	gal	galProjectList
Dropdown	drp	drpDepartment
Combo Box	cmb	cmbStatusFilter
Date Picker	dte	dteStartDate
Checkbox	chk	chkIsActive
Toggle	tgl	tglDarkMode
Form	frm	frmEmployeeEdit
Image	img	imgCompanyLogo
Icon	ico	icoRefresh
Container	con	conHeaderSection
Radio	rad	radPriority
Slider	sld	sldVolumeControl
Rating	rtg	rtgFeedbackScore
Timer	tmr	tmrSessionTimeout
HTML Text	htm	htmRichContent
Camera	cam	camIDCapture
Microphone	mic	micVoiceNote
Audio	aud	audWelcomeMessage
Video	vid	vidProductDemo
Barcode Reader	bar	barAssetScanner
Map	map	mapLocationPicker
PDF Viewer	pdf	pdfContractView
Rich Text Editor	rte	rteNoteEditor
Power BI Tile	pbi	pbiSalesReport
Add Picture	pic	picProfileUpload

Here is a screenshot for your reference:

Adding Context to Control Names

Here’s a trick that makes a huge difference: add screen or module context to your control name when the same control type appears on multiple screens.

Instead of just btnSave, use btnSave_EmployeeEdit or btnSaveEmployee depending on what feels more natural to you. This way, when you’re inside a formula referencing another screen’s control, you instantly know where it belongs.

Examples:

• btnAddOrder_HomeScreen — an “Add” button on the Home screen
• btnAddOrder_SummaryScreen — the same “Add” button but on the Summary screen
• galEmployees_BrowseScreen — the employee gallery on the Browse screen

Also, use action-based names. Don’t just say what the control is — say what it does.

• ❌ btnForm → ✅ btnSubmitForm
• ❌ lblText → ✅ lblWelcomeMessage
• ❌ imgLogo → ✅ imgCompanyLogo

Power Apps Variable Names

Variables are where things can get really messy, really fast — especially when you mix up global and local variables without a clear naming system.

In Power Apps, you have two types of variables:

• Global Variables — available across the entire app, set using Set()
• Local Variables (Context Variables) — available only within a specific screen, set using UpdateContext()

The format I use is:

[scope][DataType][Purpose]

• Global variable prefix: gbl
• Local variable prefix: loc

Examples of global variables:

• gblTextUserEmail — a global variable storing the user’s email as text
• gblBoolIsAdmin — a boolean global variable indicating admin status
• gblNumberCurrentYear — holds the current year as a number
• gblRecordSelectedEmployee — holds a record of the selected employee

Examples of local variables:

• locTextSearchQuery — a local variable storing the search text on the current screen
• locBoolFormVisible — controls whether a form is visible on a screen
• locColorTheme — stores a colour value for the current screen

Why include the data type? Because when you’re writing formulas, it immediately tells you what to expect. If you see gblBoolIsAdmin, you know to use it in an If() condition. If you see gblTextUserEmail, you know it’s a string. You stop second-guessing.

What to avoid:

❌ Avoid	✅ Better
Variable1	gblTextUserEmail
myVar	locBoolFormVisible
flag	gblBoolIsAdmin
temp	locRecordSelectedItem

Here is a screenshot for your reference:

One important note from Microsoft’s documentation: Power Apps allows context variables and global variables to share the same name. This can cause real confusion in your formulas, because Power Apps will default to the context variable. Adding gbl and loc prefixes prevents this problem entirely.

Boolean Variables: True/False Indicators

For boolean variables in Power Apps, use prefixes that create readable conditions:

Prefixes: Is, Has, Can, Should

Examples:

• gblIsDataLoaded – Is data finished loading
• locHasUnsavedChanges – Are there unsaved changes
• gblCanEdit – Can user edit records
• locShouldRefresh – Should data be refreshed
• gblIsOfflineMode – Is app in offline mode

This naming pattern makes your formulas read like natural language:

If(gblIsAdmin, Visible, Hidden)
If(locHasUnsavedChanges, ShowDialog, Continue)

Power Apps Collection Names

Collections in Power Apps are temporary tables that live in memory during your app session. They’re incredibly useful for storing data locally, building shopping cart–style lists, or caching data to reduce data source calls.

The naming format for Power Apps collections is:

col[DataSourceName][Purpose]

• Always start with col
• Use camelCase — no spaces
• Include the data source name so you know where the data comes from
• Be specific about the collection’s purpose

Good examples:

• colSPEmployees — a collection from a SharePoint list called Employees
• colDVProjects — a collection from Dataverse’s Projects table
• colNavigationMenu — a collection for navigation menu items (no specific data source)
• colSPITLeads — a collection of IT leads from SharePoint

What to avoid:

❌ Avoid	✅ Better	Why
colProducts	colSPProducts	Always mention the data source
col Navigation Menu	colNavigationMenu	No spaces in collection names
ColDiITLeades	colDVITLeads	Stick to lowercase prefix, fix typos

Here is an example in the screenshot below:

Check out Create Collection from SharePoint List in PowerApps

Power Apps Data Source Names

Data source names in Power Apps refer to how you label the connections you add to your app — like SharePoint lists, Dataverse tables, or SQL tables. The names you see in the Data panel and use in your formulas.

The rule here is to keep them clean, readable, and in singular form. Don’t use abbreviations.

Good examples:

• Employee instead of Employees or emp
• Marketing Project instead of Projects
• Customer Order instead of CustomerOrders

Why singular? Because Power Apps formulas like Filter(Employee, ...) read more naturally than Filter(Employees, ...). It keeps your formula language consistent and clean.

What to avoid:

❌ Avoid	✅ Better	Reason
cus	Customer	Don’t abbreviate
EmployeeRegistration	Employee Registration	Use spaces for readability
Projects	Project	Use singular form

Here is an example you can see:

Check out How to Use Attachment Control in Power Apps?

Power Apps AI Component Names

If you’re using AI Builder models inside your apps — things like form processors, barcode scanners, or the Copilot control — use these prefixes:

AI Component	Prefix	Example
Copilot	cpt	cptHRAssistant
Form Processor	fpr	fprInvoiceReader
Object Detector	obd	obdProductScanner
Text Recognizer	txt	txtReceiptReader
Barcode Scanner	bar	barAssetTracker
Business Card Reader	bcr	bcrContactCapture

Here is a screenshot for your reference:

Power Apps Naming Real-World Example

Let me show you how a real canvas app for employee leave requests would look with proper naming conventions applied:

Screens:

• Home Screen
• New Request Screen
• My Requests Screen
• Admin Approval Screen

Controls on “New Request Screen”:

• lblPageTitle — label showing “Submit Leave Request”
• dteDateLeaveStart — date picker for leave start date
• dteDateLeaveEnd — date picker for leave end date
• drpLeaveType — dropdown for leave type
• txtComments — text input for additional comments
• btnSubmitLeaveRequest — submit button
• btnCancelRequest — cancel and go back

Variables:

• gblRecordCurrentUser — stores the currently logged-in user record
• gblBoolIsAdmin — true/false flag for admin users
• locBoolFormSubmitted — local flag to track if form has been submitted

Collections:

• colSPLeaveRequests — pulled from a SharePoint list
• colDVLeaveTypes — pulled from a Dataverse table

Data Sources:

• Leave Request
• Leave Type
• Employee

Just looking at those names, you can understand the entire app structure without opening a single formula. That’s the goal.

Read Power Apps Modern Header Control

Useful Tips for Power Apps Naming

Before you go, here are a few things I’ve learned the hard way:

• Rename controls immediately after you drop them on the canvas — don’t wait until the end of the project. Renaming 50 controls all at once is painful.
• Document your naming rules in a shared team document, especially if you’re working with citizen developers who might not be familiar with these standards.
• Review your conventions periodically — as your app grows, naming patterns may need slight adjustments. That’s okay. Just update the documentation.
• Control names must be unique across the entire app, not just per screen. So if you have a lblTitle on every screen, add screen context: lblTitle_HomeScreen, lblTitle_EditScreen.
• Never use spaces or special characters in variable, collection, or control names — only screen names use spaces.

Conclusion

Naming conventions in Power Apps aren’t just a best practice — they’re what separates a professional app from a messy one. When you follow a consistent system for naming your screens, controls, variables, collections, and data sources, you build apps that are easier to read, easier to debug, and easier to hand off.

Naming conventions might feel like extra work when you’re in the middle of building an app, but it is really important.

The system I’ve shared here isn’t complicated. Use prefixes for controls, separate global and local variables clearly, name your screens in plain English, and keep everything consistent. That’s really all there is to it.

You may also like:

• Power Apps Button Control OnSelect Property
• Preferred Solution in Power Platform
• Power Apps Modern Spinner Control
• Power Apps Modern Combobox Control