Build Maintainable Canvas Apps with Consistent Naming

When you open a Power Apps canvas app that was built by someone else (or by yourself a few months ago) and find controls named Label_44, TextInput_23, and Button_12, you immediately know that navigating the app’s logic will be painful. A few extra seconds spent naming each element upfront can turn a confusing jungle of Auto‑generated IDs into a readable map of your app’s functionality.

This article proposes a lightweight but effective naming system. It is flexible enough to adapt to your team’s style while keeping the core benefit: anything you read in a formula tells you exactly what kind of element it is, where it lives, and what it does.

We’ll illustrate the conventions through a practical scenario: a simple Leave Request app that employees use to submit time‑off requests.

The Scenario

Imagine you are asked to fix a leave request app. The original maker named controls like this:

• Screen1 (contains two more screens: Screen2 and Screen3)
• txt for the employee’s name
• drp for the leave type
• Submit (a button)
• colData (a collection)

You quickly realise that txt is a text input and drp is a dropdown, but you have to open every screen to find out which screen they belong to. The collection colData gives no hint about its source, so you spend time tracing ClearCollect calls.

After implementing a consistent naming convention, the same app looks like this:

Screen:  Requests Screen
Controls:
txt_Requests_EmployeeName
drp_Requests_LeaveType
btn_Requests_Submit
gal_Requests_History
Collections:
colSpEmployees          (from SharePoint)
colDvLeaveRequests      (from Dataverse)

Every name is now predictable. Let’s break down the rules used.

Naming Screens

A screen’s name is the first thing a screen reader announces. Avoid cryptic suffixes or missing the word “Screen”. Use Proper Case and append the word Screen to describe its main purpose.

Good:
Requests Screen
Approvals Screen
Profile Screen

Avoid:
Requests           (missing "Screen")
requestsScreen     (not friendly to screen readers)
ScrRequests        (unnecessary abbreviation)

If a screen has more than one responsibility, consider splitting it into separate screens.

Control Naming – Abbreviation + Screen + Purpose

Controls are referenced constantly in formulas. The fastest way to find them with autocomplete is to start typing the control type. Therefore the name should begin with a standard abbreviation for the control.

The general format is:

[abbreviation]_[ScreenName]_[Purpose]

Use CamelCase for the purpose part and separate the three parts with underscores. Examples:

• txt_Requests_EmployeeName
• drp_Requests_LeaveType
• btn_Requests_Submit
• lbl_Requests_Error
• gal_Requests_History

Suggested Control Abbreviations

Pick an abbreviation for each control type and stick to it. Here is a starter set (notice we use short, memorable forms):

You can extend this list as needed. The important thing is that your team agrees on the set and uses it every time.

What to Avoid

• Names like btnSubmit_Requests – the screen suffix is at the end; order matters.
• Using nonstandard abbreviations that no one recognises (gld for Gallery, bttn for Button).
• Omitting the control type prefix – EmployeeName could be a label, text input, or a variable.

Variable Naming – Scope + DataType + Purpose

Variables are created with Set, UpdateContext, or With. Their names should immediately tell you where they are available (scope) and what kind of data they store (data type). Use PascalCase with no underscores except possibly to separate scope if you prefer.

Recommended format: [scope][DataType][Purpose]

Scope Prefixes

Data Type Suffixes

Examples

// Global variables
Set(gblTxtCurrentUser, "jdoe@contoso.com");
Set(gblRecRequestSelected, LookUp(Requests, ID = 5));

// Local variables
UpdateContext({locNumErrorCount: 0});
UpdateContext({locBoolSubmitting: false});

// With variables (often short-lived)
With(
  {varNumDaysRemaining: DateDiff(Now(), LeaveEndDate)},
  ...
)

Collections – Source + Purpose

Collections are in‑memory tables. Their names should reveal whether the data comes from an external source or is generated inside the app. Use the prefix col, then an abbreviation for the source, then a descriptive name.

Examples

// From SharePoint
Collect(colSpEmployees, ...);

// From Dataverse
ClearCollect(colDvRequests, ...);

// Created in-app
ClearCollect(colSelectionHistory, ...);

Bad examples:

• colData – no source hint, too generic.
• Employees – missing col prefix, could be a datasource name.
• col_SalesLocal – inconsistent mixture of underscores and casing.

Data Sources – Easily Readable Names

Data source names come from the connected service (SharePoint list, Dataverse table, SQL view). Whenever possible, rename the data source in Power Apps to a Proper Case, human‑readable name. You can change the display name without affecting the backend.

Good:
Employees
Leave Requests
Project Codes

Avoid:
emp          (abbreviation)
LeaveRequests (no space, harder to read)
tblLeaveReq   (technical prefix not needed)

Common Mistakes and Troubleshooting

• Over–abbreviating: Using two letters for a control type (tx for text input) makes autocomplete too broad. Three or four letters is the sweet spot.
• Inconsistent casing: drp_requests_name + drp_Requests_Name in the same app causes confusion. Decide whether to treat the screen part as Proper Case once and enforce it.
• Omitting the type prefix on labels: Labels are used a lot and tempted to skip the lbl_ prefix because “everyone knows it’s a label”. But when you later need to convert it to a text input, the name no longer fits and gets out of sync.
• Variables without scope or data type: gblTxtUserEmail tells you more than UserEmail.
• Assuming collections are temporary: Always include the source hint; it reminds you to refresh or save data back.

If you encounter an app with no conventions, start by renaming the most heavily used controls and variables one section at a time. Keep a cheat sheet of abbreviations nearby and run a quick peer review after the first round.

Security, Delegation, and Performance Notes

A naming convention does not directly affect delegation or security. However, well‑named controls and variables make it much easier to spot potential delegation issues when you read formulas. For example, if you have a gallery gal_OpenOrders that references colSqlOrders, you immediately know the data source is SQL Server and can review whether the filter is delegable.

Similarly, naming a variable locTxtUserRole reminds you that it holds text, not a record, so you won’t accidentally use locTxtUserRole.Email in a formula.

Final Recommendation

Choose a simple set of abbreviations and a consistent name order (type > screen > purpose). Write them down in your team’s wiki or in a comment inside the app’s first screen. Review the naming during code reviews as seriously as logic. A small investment in naming discipline pays back every time you open the app.

References

• Original article inspiration: Matthew Devaney – Power Apps Naming Conventions For Canvas Apps
• Microsoft Learn: Create a canvas app from a template in Power Apps (general naming guidelines may differ)
• Microsoft Learn: Canvas app controls and properties (official control names)