Keep Your Power Apps Clean: A Naming Standard That Works

Naming conventions may seem like a minor detail, but they are one of the fastest ways to turn a chaotic app into a codebase that anyone on the team can read and modify. A consistent naming strategy saves time during development, reduces bugs, and makes your app accessible to screen readers. This guide presents a practical standard for naming screens, controls, variables, collections, and datasources in Power Apps.

What We'll Build – A Compliance Inspection App

To make the conventions tangible, imagine you're creating a field inspection app. It lets inspectors view their schedule, record findings on an asset, and generate a report. The app uses Dataverse for background data and stores temporary data in collections.

Screens:

• Schedule Screen – shows today's inspections
• Inspection Form – where findings are entered
• Report Preview – shows a summary before submission
• Admin Dashboard – for managers

Controls on the Inspection Form include text inputs for notes, a drop‑down for findings, a gallery of checklist items, a submit button, and a star rating for severity.

Naming Screens

Every screen must end with the word Screen so that it's immediately clear what the object represents, and so a screen reader announces it properly. Use PascalCase (also called proper case) for the descriptive part.

Naming Controls

A control name should encode its type, its purpose, and the screen it lives on. Use camelCase for the first two parts and underscores as separators. The pattern is:

prefix_ScreenName_Description

The prefix tells you what kind of control it is at a glance. Here are the most common prefixes:

Examples from our inspection app:

• txt_InspectionForm_Notes – a text input for notes on the Inspection Form
• drp_InspectionForm_Findings – a drop‑down for selecting a finding
• btn_ReportPreview_Submit – the submit button on the Report Preview screen
• gal_Schedule_Inspections – the gallery that lists inspections on the Schedule Screen

Avoid generic names like txtNotes (no screen) or btnSubmit_Report (wrong order). The screen portion should come after the prefix so that controls from the same screen sort together in the tree.

Naming Variables

Variables should indicate their scope and their purpose. Scope tells you if the variable is available app‑wide (gbl), local to a screen (loc), or used only within a component (cmp). Never include the data type in the name – the type can change during development.

// Global variable – current user
Set(gblCurrentInspector, User().Email);

// Local screen variable – loading indicator
Set(locInspectionsLoading, true);

// You can still use a descriptive purpose without hanging the type on it:
Set(locCacheRefreshTimestamp, Now());

Naming Collections

Collections (in‑memory tables) should follow the pattern col + abbreviated datasource + description. Use a short abbreviation for the original source so you know where the data came from.

// Collection from Dataverse – active assets
ClearCollect(colDvActiveAssets, Filter(Assets, Status = "Active"));

// Collection created in app – temporary navigation items
Set(colNavigationMenu, Table({Title:"Schedule", Icon:"Calendar"}, {Title:"Reports", Icon:"Document"}));

• Good: colSpInspections, colDvChecklistItems, colNavigationMenu
• Bad: colinspections (no capitalization, no source), colDv_inspections (underscore in wrong place), colData (too generic)

Naming Datasource Tables

When you create a custom datasource inside Power Apps (like a local table), use a singular noun, no spaces, with PascalCase. The name should clearly describe what one record represents.

Common Mistakes and How to Avoid Them

Inconsistent capitalization. Stick to PascalCase for screen and datasource names, camelCase for variable and collection descriptions. Don't mix gblUserEmail with GblUserEmail.

Using data types in names. You might start with a number in a variable, but later change it to text – the name would then lie. Avoid locNumberTotal, txtInputString.

Spaces in names. They break formulas and confuse screen readers. Use underscores or camelCase only.

Forgetting the screen component in control names. Two controls with the same purpose on different screens become impossible to distinguish. Always include the screen name after the prefix.

Final Recommendation

Adopt this naming standard as a team, document it in your project wiki, and enforce it through pull‑request reviews. The upfront effort is small, but the long‑term payoff is huge: formulas that read like plain English, a control tree that sorts itself, and a codebase that doesn't require the original author to understand.

Start with one app, rename everything consistently, and see how much easier your next feature becomes.

References

• Matthew Devaney, Power Apps Standards: Naming Conventions – Original article
• Microsoft Learn, Power Apps naming best practices – placeholder
• Microsoft Learn, Accessibility in Power Apps – placeholder