DEV Community: Matt Hummel

Power Apps Filter vs LookUp vs Collections (Quick Guide for Beginners)

Matt Hummel — Sat, 04 Apr 2026 15:18:14 +0000

If you're learning Power Apps, these three come up fast:

Filter
LookUp
Collections

They’re simple on their own — but easy to mix up.

Keep This Straight

Filter → multiple records (table)
LookUp → one record
Collections → stored data in memory

Most issues come from ignoring that.

Where Things Go Wrong

Common mistakes:

Using LookUp when multiple results exist
Using Filter when you only need one record
Storing everything in a collection “just in case”

The app might still work at first… then break later.

Quick Examples

Filter (for lists)
Filter(Requests, Status = "Approved")
LookUp (for one record)
LookUp(Users, Email = User().Email)
Common mistake
Filter(Users, Email = User().Email)

Now you’ve got a table, not a record — which complicates everything later.

Filter + LookUp LookUp( Filter(Orders, Status = "Pending"), OrderID = varOrderID ) Collections ClearCollect(colOrders, Orders)

Use when reusing data — not for everything.

Real Example That Breaks

LookUp(Approvals, Status = "Pending")

Works… until multiple records match.

Better:

Filter(Approvals, Status = "Pending")

Simple Rule

Need a list → Filter
Need one record → LookUp
Need to store data → Collections

Final Thought

Most issues aren’t complicated — just small misunderstandings early on.

And your app will usually still work… until it doesn’t.

🔗 Full Post

[https://bit.ly/filter-lookup]

💬 Question

What’s something confusing you’ve run into with Filter or LookUp?

Your Power App Isn’t Slow — It’s Built Wrong

Matt Hummel — Sun, 29 Mar 2026 01:50:24 +0000

Why Most Power Apps Feel Slow (It’s Not the Platform)

Most slow Power Apps aren’t a platform issue — they’re a design issue.

Apps usually start off fine… then slowly get worse.

Longer load times, laggy clicks — just frustrating to use.

The tricky part?

It’s almost never one big problem.

It’s a bunch of small things stacking up.

Common Causes of Slow Power Apps

Here are some of the biggest ones I’ve run into:

1. Loading Too Much Data

It’s easy to pull in everything, but that slows things down fast.

👉 Only load what the screen actually needs.

2. Too Much on One Screen

Trying to do everything on one screen makes it heavy.

👉 Break things into smaller screens.

3. Overcomplicated Formulas

When formulas stack on top of each other (especially with lookups), performance drops.

👉 Simpler formulas usually run faster.

4. Repeated Data Calls

Calling the same data source over and over adds unnecessary load.

👉 Pull the data once, store it, and reuse it.

5. Ignoring Delegation

If your app isn’t returning all the data you expect, it’s likely not performing well either.

👉 Pay attention to delegation warnings early.

6. Everything Runs on Load

When everything fires at once, users are stuck waiting.

👉 Spread logic out instead of doing everything upfront.

7. No Feedback to the User

Even small delays feel worse when nothing is happening.

👉 Add loading indicators or simple feedback.

Final Thoughts

None of this is complicated.

But when you’re building fast, it’s easy to miss.

Fixing even a couple of these can make a noticeable difference in how your app feels.

What About You?

What’s the biggest thing that slowed your Power Apps down?

Or something you fixed that made it noticeably faster?

Power Apps Beginner Guide: How I’d Build My First App (Step-by-Step)

Matt Hummel — Sun, 22 Mar 2026 05:57:19 +0000

When I first started learning Power Apps, I felt stuck almost immediately.

There were a lot of concepts thrown at me all at once — data sources, galleries, forms, formulas — and most tutorials either skipped steps or assumed I already understood part of the platform.

Looking back, I think I made it harder than it needed to be.

If I had to start over today, I wouldn’t try to learn everything upfront. I’d just build a simple app that teaches the core patterns.

Here’s exactly what I would do.

What You Should Build First

Don’t try to build something impressive right away.

Start with an app that:

connects to a data source
displays a list of records
lets you view or edit a single item

That’s it.

This pattern shows up in most real-world Power Apps. Once you understand it, everything else starts to make more sense.

Step 1: Create a Canvas App

Go to:

Create → Canvas App → Tablet

At this stage, don’t worry about layout or styling. Focus on getting something working.

Step 2: Connect a Data Source

Use something simple like a SharePoint list or Excel file.

Example structure:

Title
Status
Created

One thing I didn’t realize early on — your app is only as good as your data. Keeping this simple makes everything easier.

Step 3: Add a Gallery (Your List View)

Insert a vertical gallery and set:

Items = YourDataSource

Step 4: Add a Form (Details View)

Insert an Edit Form and connect it to the same data source.

Set:

Item = Gallery1.Selected

Step 5: Add a Save Button

Add a button and set:

SubmitForm(Form1)

At this point, you have a working app.

It may not look great, but it functions — and that’s what matters early on.

Optional: Add Navigation Between Screens

If you want to make it feel more like a real app, add a second screen.

Then use:

Navigate(Screen2)

A common structure is:

Screen 1 → list of items
Screen 2 → details/edit form

What Slowed Me Down Early On

There were a few things that made learning Power Apps harder than it needed to be:

trying to understand everything before building anything
overcomplicating the first app
focusing too much on UI early
using variables everywhere without a clear reason

None of those helped at the beginning.

What Actually Matters

If you’re just starting out, focus on understanding:

galleries
forms
basic formulas

That foundation carries you much further than trying to learn advanced concepts too early.

Final Thoughts

Your first Power Apps app doesn’t need to be impressive.

It just needs to work.

Once you’ve built something simple end-to-end, the rest of the platform starts to feel a lot more approachable.

What About You?

If you’re learning Power Apps right now:

What are you trying to build?
What’s been the most confusing part so far?

I’m curious to hear how others are approaching it.

Power Apps Delegation Explained (Why Your App Only Shows 500 Rows)

Matt Hummel — Wed, 11 Mar 2026 16:51:11 +0000

When I first started building Power Apps, delegation warnings confused me more than almost anything else.

My app worked perfectly during testing.

The gallery filtered correctly.

The formulas looked fine.

Then later users started saying something strange:

“Why can’t I find this record?”

The data existed in the SharePoint list, but it wasn’t showing in the app.

After some digging I discovered the problem.

Delegation.

If you're newer to Power Apps, this is one of the most common issues you'll run into.

What Delegation Actually Means

Delegation simply means Power Apps asks the data source to do the filtering instead of doing it locally.

Example:

You have a SharePoint list with 10,000 records.

If the query is delegable, Power Apps sends the request to SharePoint like this:

"Give me all records where Status = Approved."

SharePoint does the filtering and returns the results.

Fast and scalable.

But if the formula isn't delegable, Power Apps downloads a limited number of records first and then filters them locally.

And that’s where problems begin.

The 500 Row Limit Problem

By default, Power Apps only retrieves:

500 rows
or up to 2000 rows if you change the setting

If your filter isn’t delegable, Power Apps only checks those rows.

That means if the record you want is row 3000, the app will never find it.

The data exists.

But Power Apps never downloaded it.

A Common Delegation Mistake

Here’s a filter that causes delegation problems.

Filter(Employees, Year(StartDate) = 2025)

This requires Power Apps to extract the year from every row locally.

Because of that, the query cannot be delegated.

A Delegable Version

Instead of extracting the year, use a date range.

Filter( Employees, StartDate >= Date(2025,1,1) && StartDate <= Date(2025,12,31) )

Now the data source can handle the filtering.

No delegation warning.

And your app will work correctly with large datasets.

The Warning Sign to Watch For

Power Apps actually tries to warn you.

You’ll see a blue underline under part of your formula with a message like:

"This function may not work correctly on large data sets."

Early on I ignored those warnings.

Later I learned they were telling me exactly what the problem was.

Now I treat them like an early signal something might break once the data grows.

A Simple Rule That Helps

One rule that helped me avoid delegation issues:

If the data source can do the filtering, let it.

That usually means:

Keep filters simple
Avoid manipulating columns inside filters
Let SharePoint or Dataverse handle the query

Your apps will scale much better.

Quick Takeaways

If you're newer to Power Apps, remember this:

Delegation means the data source handles the query
Non-delegable formulas only evaluate 500–2000 rows
The blue underline warning usually means your formula may break later

Once you understand that, delegation becomes much easier to work with.

Final Thoughts

Delegation was one of the hardest concepts for me to understand when I first started building Power Apps.

Mostly because the app still seems to work during testing.

Then later when your data grows, problems start appearing.

Once you understand how Power Apps queries data sources, though, the behavior starts to make sense.

And learning to spot delegation warnings early saves a lot of debugging time later.

What delegation issues have you run into when working with larger datasets?

Power Apps Variables Explained: Global vs Context vs Collections

Matt Hummel — Fri, 06 Mar 2026 03:55:48 +0000

When I first started learning Power Apps, variables confused me more than almost anything else.

At first they all seemed the same:

Global variables
Context variables
Collections

They all store data, so why do three versions exist?

After building a few apps, the difference finally clicked. The real distinction is scope and purpose.

Once you understand where each variable should live, building Power Apps becomes much easier.

Let’s break it down in plain language.

Global Variables

Global variables are available anywhere in your app.

You create them using the Set() function.

These are useful when you need to store information that multiple screens need to access.

Common examples include:

Current user information
Selected record IDs
App-level settings
Navigation state

Example:

Set(varUserEmail, User().Email)

Now varUserEmail can be used anywhere in the app.

You’ll often see global variables created when a button is clicked or when a user selects something from a gallery.

Think of global variables as shared memory across the entire app.

Context Variables

Context variables only exist on a single screen.

They are created using UpdateContext().

These are perfect for controlling screen behavior and UI elements.

Examples include:

Opening or closing popups
Showing or hiding containers
Tracking selected items within the screen

Example:

UpdateContext({showPopup:true})

If you navigate to another screen, that context variable disappears.

This limited scope is actually a good thing because it keeps screen logic contained and easier to manage.

Think of context variables as screen-level state.

Collections

Collections are different from the other two because they store tables of data.

You create them using Collect() or ClearCollect().

Collections are useful when you want to:

Store temporary datasets
Cache data for performance
Modify records before saving them

Example:

ClearCollect(colEmployees, Employees)

Now colEmployees contains a table of employee records that you can filter, update, or display in galleries.

Think of collections as temporary in-memory tables inside your app.

Quick Comparison

Here’s the simple way to remember the difference.

Global variables
App-wide values used across screens.

Context variables
Screen-level variables used for UI logic.

Collections
Tables of data stored locally inside the app.

When I Usually Use Each One

After working with Power Apps for a while, this became my general rule:

Use global variables when multiple screens need the value.
Use context variables when the value only matters on the current screen.
Use collections when you're storing multiple records or manipulating data.

That small distinction makes apps much easier to structure and debug.

Final Thoughts

Variables are one of those concepts that seem confusing at first, but once they click, your Power Apps development gets much smoother.

Understanding the scope of each variable type helps keep your apps cleaner and easier to maintain.

What About You?

How do you usually structure variables in your apps?

Do you rely mostly on global variables, or try to keep things scoped with context variables?

Always curious how other Power Apps developers approach this.

Power Apps Naming Conventions I Wish I Used From Day One

Matt Hummel — Wed, 04 Mar 2026 00:17:49 +0000

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?

Pull Office 365 User Data in Power Apps (Simple Example)

Matt Hummel — Tue, 03 Mar 2026 22:06:53 +0000

Pull Office 365 User Data into Power Apps

One problem I ran into early when building Power Apps was working with user information.

Things like:

Who is the current user?
What department are they in?
Who is their manager?

At first I handled this the wrong way — manually storing user data in lists or tables. That works for small demos, but it quickly becomes messy in real apps.

A better approach is using the Office 365 Users connector, which pulls user information directly from Microsoft 365.

Why This Is Useful

User data shows up in a lot of apps:

approval workflows
assigning records
sending emails
filtering data by user

Instead of maintaining a separate user list, you can pull the data directly from your organization’s directory.

Add the Office 365 Users Connector

In Power Apps Studio:

Open Data
Click Add data
Search for Office 365 Users
Add the connector

Once it’s added, you can start using it in formulas.

Get the Current User

Power Apps already provides a simple function:

User().FullName User().Email User().Image

For many apps, this is all you need.

Get More Profile Information

The Office 365 Users connector lets you retrieve additional profile data.

Office365Users.MyProfile()

Examples:

Office365Users.MyProfile().DisplayName Office365Users.MyProfile().JobTitle Office365Users.MyProfile().Department Office365Users.MyProfile().Mail

This lets you display things like job title or department inside your app.

Get a User’s Manager

This is especially useful for approval apps.

Office365Users.Manager(User().Email).DisplayName

Get a User’s Manager

This is especially useful for approval apps.

Office365Users.Manager(User().Email).DisplayName

Or retrieve their email:

Office365Users.Manager(User().Email).Mail

Now approvals can automatically route to the correct manager.

Performance Tip

Avoid calling the connector repeatedly across many controls.

Instead store the profile in a variable when the app loads:

Set(varUserProfile, Office365Users.MyProfile())

Then reference the variable:

varUserProfile.DisplayName varUserProfile.Department varUserProfile.JobTitle

This keeps your app faster and formulas cleaner.

Final Thoughts

When I first started working with Power Apps, I didn’t realize how much useful data was already available through Microsoft 365 connectors.

Using the Office 365 Users connector makes it easy to:

retrieve user profiles
find managers
personalize apps

Reduce manual data maintenance

If you're building internal business apps, this connector quickly becomes one of the most useful tools in Power Apps.

I’m currently documenting my Power Platform learning journey and sharing what I learn while building real apps.

From Reader to Contributor: Why I’m Finally Posting on Dev.to

Matt Hummel — Tue, 03 Mar 2026 12:42:29 +0000

Why I’m Finally Posting on Dev.to

I’ve been reading Dev.to for a while.

I’ve learned from other builders here. Picked up patterns. Solved problems because someone else shared theirs.

But I never posted anything myself — until now.

For the past few years, I’ve been working in the Microsoft Power Platform after spending about 15 years building traditional web projects. And honestly, the transition wasn’t smooth.

Delegation errors confused me.
I mixed up triggers and actions.
I built flows that ran way more times than they should have.

Low-code didn’t mean simple.

Over time, though, something clicked. The Power Platform isn’t about replacing “real development.” It’s about solving business problems faster — especially when requirements change constantly.

Most of what I’ve learned came from breaking things in real projects and figuring out why they broke.

That’s what I’ll share here:

• Practical Power Apps lessons
• Common Power Automate mistakes
• What I’d do differently now
• Real-world patterns that actually scale

No polished demos. No marketing spin. Just honest lessons from someone building and learning as he goes.

If you’re newer to Power Platform — or transitioning from traditional dev like I did — you’re not alone.

Let’s build smarter.