Power Apps Canvas App Naming Conventions and Coding Standards

Every canvas app starts clean and ends up mysterious: Button5 next to Button5_1, a variable called temp2, and a collection named MyCollection that nobody dares to delete. Naming conventions are how teams stop that slide. They are shared rules for naming screens, controls, variables, collections, and data sources so that any maker — including you in six months — can read a formula once and understand it.

This guide collects the conventions the maker community has converged on, alongside Microsoft's official coding guidelines: screen names in plain words, short type prefixes on controls, scope prefixes on variables, source-aware collection names, and singular data source names. It also rounds up the best online resources at the end so you can keep going.

The one rule: consistency beats perfection

Two camps argue about the details — prefixes or no prefixes, underscores or pure camelCase — and both ship working apps. The research and every community thread agree on one thing: a team that applies an imperfect standard consistently outperforms a team where every maker invents their own. Write your standard on one page, link it from your team wiki, and review against it.

• Rename as you build. Fixing Button14 the moment you add it takes seconds; renaming 200 controls before go-live takes a weekend.
• Use the Format text command in the formula bar so indentation and spacing stay uniform across makers.
• Run App Checker before every release — it catches the accessibility and performance issues that sloppy naming usually hides.
• Review with the Power CAT code review toolkit, which flags patterns that break the official coding guidelines automatically.

Screen names

Screen names are the only names in Power Apps that should contain spaces. Write 2–3 plain words and always end with the word Screen. Screen readers announce the name when the screen loads, so OrderFormScreen is heard as one garbled word while Order Form Screen is heard correctly. A tree view of plain-language screens is also its own navigation map.

Control names

A control name answers three questions at a glance: what type is it, what is it for, and where does it live. The community pattern is prefix_Purpose_Screen in camelCase with underscores between the segments — for example, txt_Order_LastName is a text input capturing last name on the Order screen. The underscores visually separate the type tag from the purpose, which is why this pattern stuck even though pure camelCase is more familiar to pro developers.

Two mechanics to respect: control names must be unique across the whole app, not just the screen, so repeat controls earn their screen segment (lbl_Home_Title, lbl_Orders_Title). And never ship default names — Button5 tells the next maker nothing, while btn_Home_Save tells them everything.

Standard control prefixes

Three-letter type tags are the heart of the system. The list below merges Microsoft's current coding guidelines with long-standing community prefixes, including modern controls. Learn the dozen you touch daily; look up the rest on demand.

Variable names

Variables carry scope, so their names should show it. Prefix globals set with Set using gbl and screen-scoped context variables set with UpdateContext using loc, then describe the purpose in camelCase with no spaces: gblCurrentUserEmail, locSelectedOrderId. Typing gbl in the formula bar then lists exactly the globals in scope — the fastest navigation aid in the whole standard.

Scope prefixes also prevent a real bug class: Power Apps allows a context variable and a global variable to share a name, and formulas resolve to the context variable first. Distinct prefixes make that collision structurally impossible.

• Keep data types out. Name the purpose, not the storage — locIsSaving, never locBoolSaving. Types change; purposes do not.
• Booleans read as questions. Start flags with Is, Has, Can, or Should: gblIsDataLoaded, locHasUnsavedChanges. Conditions then read like English.
• Short-lived temporaries get var. Inside a With block, var marks values that exist for one formula only.
• App-level reusable values get fx. Named formulas are neither variables nor controls, so community practice gives them their own tag: fxBrandColors, fxWorkingDays.

Collection names

A collection name records where the data came from and why it exists: col, then the source abbreviation, then the purpose — colDvInvoices is invoices pulled from Dataverse. When a collection is built purely in the app with no outside source, skip the source segment: colNavigationMenu.

Data source names

Name tables and lists your team creates with 1–3 full words in PascalCase, singular, no abbreviations: Employee, Construction Project, Repair Order. Singular names keep formulas grammatical — Filter(Leave Request, Status = Open) — and full words survive staff turnover where abbreviations like Emp do not. Note that names inherited from a connector (Office365Users, for example) cannot be renamed in the app, so apply this rule to the sources you own.

Components and custom properties

Components are mini-apps with their own surface: keep their internal controls on the same standard, and name custom input and output properties in PascalCase (SelectedOrder, OnSave) so they read like built-in properties at the call site. If a component is reused across apps, treat its property names as a public contract — renaming one later breaks every consumer.

Duplicating screens without rename pain

Template screens are a great accelerator until Power Apps duplicates every control with a _1 suffix and you face twenty renames. Two habits keep it cheap: put the screen segment last (con_Main_Header rather than burying it), so a single find-and-replace of the old screen token renames the batch; and duplicate from a template whose controls already follow the standard, so the only edit is the screen token itself. Either segment order works if you are consistent — but pick the order before the team grows, not after.

Do you even need prefixes?

A vocal school argues prefixes are 1990s Hungarian notation that modern tooling made obsolete: intent matters more than type, and the tree view already shows icons. It is a fair critique of pro-code IDEs — and it mostly misses why prefixes persist in canvas apps. The control set is small and fixed, the formula bar groups by typed prefix, and intellisense will not tell you a gallery from a table at a glance. Prefixes are a working compromise for this specific studio, not a universal law. Adopt them, or consciously adopt the alternative — then enforce whichever you chose.

Adoption checklist

• Screens use plain words and end with Screen.
• Controls follow prefix_Purpose_Screen and are unique across the app.
• Globals use gbl, context variables use loc, With-block temporaries use var, named formulas use fx.
• Collections carry col plus source abbreviation plus purpose.
• Owned data sources are singular PascalCase with no abbreviations.
• No default names (Button5, Label3, Screen1) survive to release.
• Format text is applied, App Checker is clean, and a reviewer signs off against this page.

Further reading

Naming is one chapter of a bigger discipline. These are the resources this guide is built on and the ones to open next — each opens in a new tab:

• Power Apps Standards: Naming Conventions — Matthew Devaney: the community reference this page aligns with, including the full standards series on variables, comments, theming, and performance.
• Power Apps coding guidelines — Microsoft Learn: the official, maintained guidelines for consistent, performant, maintainable apps.
• Code readability, including naming conventions — Microsoft Learn: the official control-prefix table and variable guidance.
• Canvas app coding standards whitepaper announcement — Microsoft: the original 2018 whitepaper that started the community conversation.
• Power Apps naming conventions with examples — SPGuides: a second worked take, including AI-component prefixes.
• PowerApps coding guidelines — Todd Baginski: the early guidelines that fed into the official whitepaper.

Inside nextM365, continue with What Is Microsoft Power Fx? for the language behind the formulas, the Power Fx function reference when you need a specific function, and the Power Apps Code hub for the pro-code side of the platform.