When I first started building Power Apps, I didn’t think naming conventions mattered.
Everything worked… until my app grew and formulas became impossible to read.
A few simple naming habits completely changed how easy my apps were to maintain.
When you first start building Power Apps, naming things doesn’t feel important.
You’re focused on getting the app working.
So you leave names like:
- Label1
- Gallery3
- ButtonSubmit2
At first it works fine.
Then your app grows… and suddenly your formulas look like a mess.
If(Label12.Visible, Gallery3.Selected.Title, TextInput5.Text)
At that point, finding anything becomes painful.
After building more apps, I realized naming conventions make Power Apps much easier to maintain.
This post covers a simple naming structure that keeps apps organized and easier to read.
Why Naming Conventions Matter
Power Apps apps can grow quickly.
One screen might contain:
- dozens of controls
- multiple variables
- several data sources
Without a naming structure, it becomes hard to understand what anything does.
Consistent naming makes apps easier to:
- read
- debug
- maintain
- collaborate on
Microsoft’s own Power Apps coding guidance recommends using consistent naming for screens, controls, variables, and collections because it improves readability and maintainability.
Think of naming conventions like organizing tools in a toolbox.
Everything has a place.
Basic Naming Pattern
A common structure for controls is:
prefix_Purpose
Example:
- btn_SubmitForm
- txt_UserEmail
- lbl_StatusMessage
The prefix tells you what type of control it is.
The name tells you what it does.
When you’re writing formulas, this saves a lot of time.
Common Control Prefixes
Here are some common Power Apps control prefixes.
Buttons
- btn_Submit
- btn_SaveForm
Labels
- lbl_Status
- lbl_ErrorMessage
Text Inputs
- txt_Email
- txt_UserName
Galleries
- gal_Employees
- gal_RequestList
Forms
- frm_Request
- frm_EmployeeEdit
Dropdowns
- drp_Department
- drp_Status
Checkboxes
- chk_Approved
- chk_IsActive
Icons
- ico_Delete
- ico_Edit
The goal is simple:
- prefix = control type
- name = what it does
So when you see something like:
btn_SubmitRequest
Many developers use these prefixes because they quickly show the control type when writing formulas.
Naming Screens
Screens should clearly describe what they do.
Example:
Good:
- Home Screen
- Employee Request Screen
- Approval Screen
Bad:
- Screen1
- Dashboard
- Page2
Descriptive screen names also help accessibility tools like screen readers understand the app layout.
Naming Variables
Variables should tell you what they store and where they are used.
Example pattern:
- gblUserEmail
- locIsLoading
- varSelectedItem
Typical prefixes:
Prefixes and Meanings
- gbl Global variable
- loc Context variable
- var General variable
This makes it easier to quickly understand the scope of a variable when reading formulas.
Naming Collections
Collections usually start with col.
Example:
- colEmployees
- colNavigationMenu
- colActiveRequests
A good rule is to describe what the collection contains.
A Real Example
Instead of this:
- Gallery1
- Label4
- Button2
Use something like:
- gal_Employees
- lbl_EmployeeName
- btn_SaveEmployee
Now your formulas read like actual logic:
btn_SaveEmployee.Visible
gal_Employees.Selected.Name
Much easier to understand.
The Most Important Rule
There isn’t one perfect naming system.
Different teams use slightly different patterns.
The important part is consistency.
A consistent naming structure makes apps easier to navigate, debug, and maintain over time.
Final Thoughts
Power Apps lets you build solutions very quickly.
But if you skip naming conventions early, the app can become difficult to maintain later.
A few simple naming habits make a big difference:
- use clear prefixes
- describe the purpose of controls
- keep names consistent
Your future self will thank you.
Curious what naming conventions other Power Apps developers are using. Do you follow a standard pattern or something different?
Top comments (0)