DEV Community: Matt Hummel

WordPress Abilities API integration — A Practical First Integration

Matt Hummel — Fri, 04 Sep 2026 16:32:53 +0000

Introduction

This post walks through a practical WordPress Abilities API integration for developers and product teams. It shows how to declare discoverable, executable abilities (name, schema, callback) so external tools, automation, and AI agents can find and run site functionality. The goal here is to give you a safe, minimal first integration and a straightforward path for promoting and engaging with it once it’s live.

What the Abilities API is and why it matters

The Abilities API was added to WordPress to make site capabilities both machine-readable and executable. It arrived in WordPress 6.9 and provides a standard registry for actions your site can perform. (developer.wordpress.org)

Why it matters: abilities make your site discoverable to integrations, enforce consistent parameter schemas, optionally expose functionality via REST, and give automation and AI tools a predictable way to execute tasks.

Quick overview: register an ability

At the heart of a WordPress Abilities API integration is wp_register_ability(). Use it to declare an ability's name, description, JSON schema for parameters, and the callback that performs the work. This is how you make tasks like "create-draft", "sync-product", or "triage-comment" visible to other systems. (developer.wordpress.org)

Minimal example

add_action( 'wp_abilities_api_init', function() {
  wp_register_ability( 'my-plugin.create_draft', [
    'title'       => 'Create draft post',
    'description' => 'Create a draft post with title and content',
    'meta'        => [ 'show_in_rest' => true ],
    'args'        => [
      'title'   => [ 'type' => 'string' ],
      'content' => [ 'type' => 'string' ],
    ],
    'callback'    => function( $args ) {
      return wp_insert_post( [
        'post_title'   => $args['title'],
        'post_content' => $args['content'],
        'post_status'  => 'draft',
      ] );
    }
  ] );
} );

Setting show_in_rest gives you automatic REST endpoints and makes the ability discoverable through the Abilities REST routes. (developer.wordpress.org)

Discovery, REST endpoints, and authentication

When you expose abilities over the REST surface, external systems can discover what your site can do and what parameters each ability expects. The Abilities REST endpoints follow the same authentication and permission model as the WordPress REST API, so apply least-privilege access when granting remote systems permission to call abilities.

Where to hook and how to structure code

Register abilities on the Abilities API init hooks (for example, wp_abilities_api_init and any category registration hooks) so they’re available for discovery and for adapters that surface them to agents. Hooking in at the right point ensures predictable availability and compatibility with other systems. (make.wordpress.org)

Integrating with AI agents (MCP adapter)

If you want to connect Abilities to AI agents and automation frameworks, look at the WordPress MCP adapter. It maps Abilities into tools and resources that agent frameworks can consume, which helps you build safe, scoped integrations between AI tooling and site functionality. (developer.wordpress.org)

Safety, permissions, and best practices

Keep abilities narrow and purpose-built. Prefer small, least-privilege actions rather than a single admin-level ability that does everything. Log executions with context (ability name, calling actor, parameters) so you can audit activity and respond to misuse. Treat any ability that performs writes as sensitive and require explicit opt-in before exposing it to external agents.

Next steps and resources

1) Build a minimal plugin that registers one read-only and one write ability. 2) Publish the project on GitHub with clear examples and tests. 3) Share the tutorial on DEV.to and a short business summary on LinkedIn; engage with comments and track clicks and leads. Use the Abilities API docs and examples as your primary references while developing. (developer.wordpress.org)

Follow this practical approach and you’ll end up with a discoverable, auditable, and promotable WordPress Abilities API integration that serves both developers and business stakeholders.

Originally published on matthummel.com.

Why I'm Moving Away from Power Platform and Back to Modern WordPress

Matt Hummel — Wed, 02 Sep 2026 05:05:11 +0000

After nearly five years of enterprise Power Platform work, I'm pivoting my content and personal projects back to modern custom WordPress development.

For the last nearly five years, a big part of my day-to-day work revolved
around the Microsoft Power Platform. Over the past few months, I began
writing about it here—sharing practical fixes for canvas app delegation,
complex formulas, SharePoint integrations, and automated flows.

However, the more I documented those enterprise processes, the more I
realized my core passion wasn't in low-code platforms. While internal business
tools solve real corporate problems, my true technical curiosity has always
belonged to full-stack web development.

Because of that, I'm making a deliberate shift: moving away from Power
Platform content and returning to my roots in modern WordPress engineering,
open-web architectures, and custom personal builds.

Here is why I'm making the change—and what I'll be sharing next.

1. Five Years in Managed Ecosystems vs. Open-Web Control

Spending nearly five years inside the Microsoft ecosystem taught me a lot
about rapid enterprise app delivery. But working exclusively within a vendor's
walled garden introduces hard limits on custom execution, data flow, and
long-term platform control.

Returning my focus to custom web development (especially modern setups using
Roots/Sage, Blade templates, Vite, and automated CI/CD pipelines) brings back
the exact aspects of engineering I enjoy most:

Total architectural control over data flow, markup, and application logic.
Direct performance tuning at the code level without vendor-imposed rules.
True open-source independence without licensing shifts or platform lock-in.

2. Modern WordPress Is a Superior Developer Experience

There is a common myth that WordPress development is stuck in the past. In
reality, modern custom theme and plugin development uses a toolchain that
matches top-tier web application engineering:

Clean templating using Blade and modern PHP features.
Instant asset compilation powered by Vite.
Streamlined developer workflows (using tools like Cursor and scoped MCP integrations) that handle repetitive boilerplate, freeing up time for architecture, accessibility, and speed optimizations.

Stepping back into custom WordPress builds reminded me how powerful, clean,
and rewarding web engineering can be when done with modern tools.

3. Building for the Web (Not Just Enterprise Specs)

Internal enterprise tools naturally focus on admin forms, internal workflows,
and corporate data entry. They serve a functional purpose, but they rarely
allow for creative experimentation with modern web APIs, public-facing user
experiences, or open-source software.

I want to spend my energy building and shipping personal web projects, such as:

Lightweight, speed-first custom WordPress plugins.
Modern theme starter stacks.
Full-stack experiments combining external APIs, modern UI, and AI workflows.

What Changes Here

No new Power Platform posts. The tutorials I published over the last few months will remain online for anyone who needs them, but my focus is moving on.
Deep-dive WordPress content. Expect practical guides on custom PHP architectures, Sage/Blade workflows, performance strategies, and modern developer tooling.
Build logs. I’ll be sharing the raw, honest engineering process behind the personal projects and tools I ship.

It took five years in the low-code world to realize how much I missed custom
web development, and I’m excited to be back in my element.

Are you building for the open web or refining your own dev stack right now?
Let's connect in the comments below.

5 Ways my new AI WordPress Workflow Actually Speeds up Development (and what it doesn't)

Matt Hummel — Wed, 02 Sep 2026 04:25:12 +0000

My AI WordPress workflow helps me finish the parts of a custom WordPress build I already know how to check. It does not replace the check.

I use Cursor inside a Sage (Roots) theme repository, ChatGPT and Claude for context/copy passes, n8n for form handling, GitHub Actions to build the theme zip, and Vite for asset compilation. Scaffolding, boilerplate, and first-pass Blade loops come back significantly quicker than they used to. Architecture, testing, and the final yes still sit with me.

Note on context: This post is a tool-by-tool breakdown of strengths, costs, and human steps—not a repeat of my previous workflow essay ("AI for WordPress Development: My Cursor, ChatGPT, n8n & MCP Workflow"). That post covers the loop; this one maps where each tool shines and where it costs.

What “Fast” Actually Means in Custom Dev

"Fast" is easy to sell. In practice, it means something much narrower: less time spent on work that does not require a human rewrite.

I won't claim a 10x multiplier or a shorter calendar on every project, nor that a model "wrote the site." The core benefit is clear: repeatable technical work shrinks, while accountability remains firmly human.

1. Repeatable Work Lessens

Renaming an ACF page field, wiring a new Vite entry point, drafting a standard Blade loop, or filling out a GitHub Actions workflow—these are predictable patterns. AI models excel here because I can immediately verify the output against a pattern I already know.

That accounts for most of the actual speed gain. It is real, but it is also easy to overstate.

2. Judgment Remains with the Developer

Deciding which plugin stays, whether a client editor can safely modify a layout field, catching contrast accessibility failures, or evaluating if a webhook belongs in the stack—that is judgment. Models guess based on statistical likelihood. I still own the call.

If I cannot explain every line at handoff, it does not ship. It's the same quality bar as a traditional build, just with less friction on the boilerplate.

The AI WordPress Tool Matrix

This isn't a tier list or a ranking. Each tool occupies a specific role in the build, incurs a specific trade-off, and demands a non-negotiable human review step.

Tool	Role / Best For	Weak At / Trade-Off	Non-Negotiable Human Step
Cursor	In-repo scaffolding, Blade templates, PHP helpers, refactoring.	Hallucinating WP core APIs or outdated package syntaxes.	Reading diffs line-by-line; testing logic in a real WP environment.
ChatGPT / Claude	Second-pass copy editing, off-repo structural brainstorming, regex.	Lacks direct codebase context; over-uses generic "agency voice."	Validating accuracy, editing tone, stripping unnecessary fluff.
n8n	External form handoff automation and webhook integration.	Silent failures if third-party endpoints rate-limit or change schemas.	Setting up fallback mail handlers (`wp_mail`) and monitoring logs.
Vite	Asset bundling, hot module replacement (HMR), asset compilation.	Requires strict entry point declarations in custom theme setups.	Auditing bundle sizes and verifying compiled output in browser.
GitHub Actions	Automated CI/CD, running Composer, building production zip releases.	Hidden pipeline costs or broken builds due to strict PHP/node mismatches.	Maintaining deployment secrets and controlling production triggers.
MCP (Model Context Protocol)	Giving agents scoped doors to external tools (database, terminal, APIs).	Risk of exposing elevated write access or leaking sensitive credentials.	Keeping scopes hyper-narrow; manually approving write operations.

How I Choose Tools per Task

I start from the job, not the model:

In-repo file edits (Sage/Roots theme): I open Cursor.
Drafting content or working outside the codebase: I use ChatGPT or Claude.
Handling form submissions and external payload routes: That is n8n.
Asset compilation & production releases: That belongs to Vite and GitHub Actions.
Connecting agents to real-time tools: MCP opens only when an agent needs a narrow doorway to an external utility.

A development shop doesn't need all of these active at once. You pick the right tool for the current step, followed immediately by human review.

How a Change Moves from Brief to Release

From a client brief to project handoff, the pipeline is short and predictable. AI models sit exclusively in the middle step—never at the boundaries.

[ Brief ] ──► [ Cursor / AI Draft ] ──► [ Human Review & Diffs ] ──► [ Vite & CI/CD ] ──► [ Production Handoff ]

Brief: A shop note, agency ticket, or custom brief. I write the technical constraints. A model did not take the job.
Cursor: Local scaffolding inside the Sage repository—Blade components, PHP helpers, Tailwind/CSS. ChatGPT/Claude assist with off-repo structural ideas. MCP is enabled only when an agent requires a specific, scoped tool.
Review: I inspect the Git diff. I execute the code on a real local page. Hallucinated APIs, unnecessary plugins, and fluff copy get eliminated here.
Vite & CI: Running npm run build locally, followed by GitHub Actions on push to main. The pipeline runs Composer, compiles assets, packages the production release zip, and tags theme-latest. PHP 8.3 serves as the runtime; WP-CLI remains the administrative interface.
Handoff: Configuring wp-admin fields for client editing, providing clean technical notes, and transferring the Git repository. If I cannot explain a piece of code, it does not get handed off.

Where n8n Sits: n8n is isolated from the theme's core code path. When a user submits a contact form, WordPress POSTs JSON to an n8n webhook. If that webhook fails, a native wp_mail fallback triggers. Automation handles the payload after submission—it does not author the theme.

What I Still Do by Hand

The list of manual tasks remains longer than the automated pipeline by design:

Architecture & Strategy: Deciding overall system structure—and what not to build.
Security & Access: Managing permissions, nonces, and governing what MCP servers can access.
Diff Auditing: Reviewing every single line in a pull request rather than trusting the commit summary.
Field & Cross-Device Testing: Validating themes on live page builds across desktop and mobile viewports.
Copy Tone: Ensuring the copy speaks clearly to clients and agencies without sounding like LLM jargon.
Accessibility (a11y): Verifying color contrast pairs, ARIA labels, semantic HTML hierarchy, and keyboard focus states.
Production Deployment Approval: Giving the final green light for production releases.

Standard VS Code is still part of my setup for times when I want to edit files without AI assistance. Keeping the review muscle sharp is critical.

FAQ

Does AI write the PHP I ship?

It drafts it; I review and ship it. Tools like Cursor, Claude, and ChatGPT help produce boilerplate PHP and initial template logic. However, I read, test, and take ownership of every line that hits production—including Vite pipelines, PHP 8.3 code, and GitHub Actions scripts.

Why is there no "overall winner" in this comparison?

Because they perform completely different functions. Cursor acts as the local code editor, ChatGPT/Claude handle off-repo reasoning, n8n routes form payloads, and GitHub Actions automates deployment zips. Ranking them against each other would be comparing apples to build servers.

Will an AI workflow like this replace a developer?

No. The cost of generating repeatable code dropped, but the cost of technical judgment did not change. Hiring an experienced developer means paying for code architecture, security verification, thorough testing, and long-term maintainability—not the speed of the prompt log.

What about data privacy and vendor lock-in?

Chat interfaces and MCP tools process whatever you pass to them. I mitigate risk by keeping write scopes minimal and removing secrets/keys from prompts. While Cursor, n8n, and GitHub represent distinct third-party dependencies, all code and review processes live inside standard Git repositories that can be migrated at any time.

How does this differ from a full workflow guide?

A workflow guide demonstrates how the ecosystem fits together during an active WordPress build. This post provides an explicit tool-by-tool comparison detailing strengths, trade-offs, and where human intervention remains mandatory.

Originally published on matthummel.com.

AI Website Redesign: 5 Lessons From a Solo Developer

Matt Hummel — Mon, 22 Jun 2026 15:51:15 +0000

I'll be honest with you: my website sat half-finished for a long time. Not because I didn't care about it, but because I'm a full-time Power Platform developer by day and a full-time dad the rest of the time. Between work and a house full of twins (and a cat who thinks he's in charge), "redesign my portfolio" kept sliding to the bottom of the list.

So I did something I'd been curious about for a while. I used AI to help me redesign on my portfolio as a one-person team. This post is the honest version of how that went — why I reached for AI, what it actually did, where it tripped up, and the lessons you can borrow for your own AI website redesign.

Why I used AI (when I'm just one person)

The short answer is time. The longer answer is that a solo dev wears every hat — designer, developer, writer, QA, and SEO person — usually after the kids are asleep.

Here's what pushed me to try it:

Time is my scarcest resource. A full-time job plus parenting doesn't leave long stretches for fiddling with CSS at midnight.
I'm a team of one. There's no designer to hand off to and no senior dev to review my work. AI became my second pair of eyes.
Context-switching is brutal. My day job is Power Platform, not front-end. AI helped me get back up to speed fast instead of relearning everything each time.
I wanted momentum. Small, finished wins beat a perfect plan I never start.

Turns out I'm not alone. In the 2025 Stack Overflow Developer Survey, 84% of developers said they use or plan to use AI tools — up from 76% the year before. AI has quietly become a normal part of how we build.

What AI actually did in the redesign

This wasn't "press a button, get a website." It was more like pair programming with a tireless junior who never gets bored of the fiddly stuff. A few real examples:

Fixed my responsive layouts. My columns refused to stack on mobile. AI found that the grids were styled inline and targeted them the right way, so the parent columns stacked without breaking the child grids.
Built a full-width gradient hero. The brand gradient kept hiding my content. The fix was putting the gradient on the outer row and making the inner column transparent — something I'd have spent an evening guessing at.
Solved a page-speed problem. My site got flagged for slow loading (Largest Contentful Paint). It turned out the slow element was my heading text waiting on a web font, not an image. One font-loading setting fixed it.
Handled the boring-but-important SEO. Meta titles, descriptions, slugs, and indexing — the stuff I always rush — got done properly.

If you want the technical background on that speed metric, Google's own Largest Contentful Paint guide is the clearest explanation out there (aim for 2.5 seconds or less).

5 lessons from my AI website redesign

If you take nothing else from this post, take these.

Diagnose before you fix. My biggest time-saver was making AI prove the cause before changing anything. The "slow page" was a font issue, not an image — guessing would have wasted hours.
Verify on the live page, not the editor. What the editor shows and what visitors actually see are two different things. Always check the real, published page.
Treat AI as a collaborator, not autopilot. I still made the calls. Fittingly, that same Stack Overflow survey found 46% of developers don't fully trust AI output — so review everything.
Make small, reversible changes. One labeled CSS block or one setting at a time. If something breaks, you know exactly what to undo.
Write down what worked. I kept a running playbook of fixes so future-me (or future-you) doesn't solve the same problem twice.

Trust, but verify: I read over everything

This is the part I won't skip, and you shouldn't either. AI is fast, but it's confidently wrong often enough that I treat every result as a draft, not a final answer.

Here's how I check accuracy before anything goes live:

I read every line of code and copy. If I don't understand why a change works, I ask until I do. No black boxes on my own site.
I test the real result. I load the live page and click around at different screen sizes instead of trusting a description of what "should" happen.
I fact-check claims and sources. Stats, links, and "best practices" get verified against primary sources before I publish them.
I sanity-check the SEO. Titles, descriptions, and slugs all get a human read for tone and accuracy, not just a green score.

The goal is simple: AI does the heavy lifting, but I'm accountable for what ships. Reviewing the output is where "using AI" turns into "using AI well."

Prompting is a skill worth practicing

The difference between a frustrating AI session and a productive one usually comes down to the prompt. Vague questions get vague answers. The more context and direction I give, the better the results.

A few habits that leveled up my prompting:

Be specific about the goal. "Make the columns stack on mobile and tablet, but don't change the inner grids" beats "fix the layout."
Give context. I mention the stack (WordPress, Kadence, SiteGround) so the answer fits my actual setup.
Ask for the cause, not just a fix. Telling AI to diagnose first leads to real solutions instead of guesses.
Iterate. I refine in small steps — "now make it responsive," "add padding to the buttons" — instead of demanding everything at once.
Set the standard. I tell it to keep things scannable, on-brand, and reversible so I don't have to redo the output.

Good prompting isn't magic words. It's clear thinking written down — and like any skill, it gets sharper the more you do it.

Troubleshooting: when AI got it wrong

It wasn't all smooth. The recurring snags were easy to fix once I knew them:

"My change didn't apply!" Nine times out of ten it was caching. Purge your cache before deciding a change failed.
Wrong element targeted. AI occasionally styled the wrong box. A quick look at the live page caught it every time.
Logged-in view fooled me. Admins bypass caching and optimizations, so test as a logged-out visitor for the real result.

Common mistakes to avoid

Letting AI publish or change settings without you reviewing first.
Bundling ten changes together, then not knowing which one broke the site.
Trusting the editor preview instead of the live page.
Skipping a backup or revision before a big edit.
Optimizing the thing you assume is slow instead of the thing you measured.

Your AI website redesign checklist

[ ] Write one sentence describing what "done" looks like.
[ ] Ask AI to diagnose and confirm the root cause first.
[ ] Make one small, reversible change at a time.
[ ] Purge the cache after each change.
[ ] Verify on the live page at mobile, tablet, and desktop widths.
[ ] Set your SEO (title, description, slug) before publishing.
[ ] Save what worked to a personal playbook.

The bottom line

AI didn't replace me — it gave a busy solo dev a way to actually finish things. As a full-time developer and full-time dad, that's the difference between a site that's "always almost done" and one that's live, fast, and something I'm proud of.

If you've been putting off your own redesign because there just aren't enough hours, this is your nudge: start small, let AI handle the heavy lifting, and keep your hands on the wheel.

Power Apps Project Planning: 7 Simple Steps to Build Better Apps

Matt Hummel — Fri, 22 May 2026 04:03:08 +0000

Learn Power Apps project planning before building your app. Use this beginner-friendly checklist to plan users, data, workflows, security, ALM, and success metrics.

Starting a new Power Apps project can be exciting.

You have an idea, you open Power Apps Studio, add a screen, connect a list, and start building. That is one of the best parts of Power Apps. You can go from an idea to something working pretty quickly.

But I have also learned that jumping in too fast can create problems later.

Sometimes the app starts simple, then suddenly you need approvals, different user roles, email notifications, admin screens, reports, and a better way to manage the data.

That is when a little planning helps.

You do not need a huge requirements document. Even a simple one-page plan can make the project easier to build, test, and support.

1. Start With the Problem

Before creating screens, write down the actual problem.

Instead of saying:

I need to build a request app.

Try something clearer:

Employees need a simple way to submit equipment requests, managers need to approve them, and admins need one place to track the status.

That one sentence gives the app more direction.

It tells you:

Who is using the app
What they are submitting
Who approves it
What needs to be tracked

A Power App does not need to solve every problem. It just needs to solve one process clearly.

2. Know Who Will Use the App

Next, list the people who will use the app.

Do not just say “users.” Break them into roles.

Role	What they need to do
Employee	Submit a request
Manager	Approve or reject a request
Admin	Review and update records
Leadership	View status or reports

Once you know the roles, it becomes easier to decide what each person should see.

The employee probably does not need the admin screen.

The manager probably only needs items waiting for approval.

The admin may need access to everything.

3. Look at the Current Process

Before building the new app, write down how the process works today.

Example:

Employee fills out a spreadsheet.
Employee emails it to a manager.
Manager replies with approval.
Admin copies the information somewhere else.
Someone manually sends status updates.

Once the current process is written down, the problems become easier to see.

Maybe approvals are getting buried in email.

Maybe people are copying the same data into multiple places.

Maybe nobody knows the current status.

4. Sketch the Future Process

Now write down what the new process should look like.

Example:

Employee submits the request in Power Apps.
The request is saved to SharePoint or Dataverse.
Power Automate sends the approval to the manager.
Manager approves or rejects it.
The request status updates automatically.
Employee gets a notification.
Admins can track everything in one place.

This gives you a simple roadmap before you build.

5. Plan the Data Before the Screens

This is one of the biggest lessons I have learned with Power Apps.

If the data is not planned well, the app gets harder to build.

Before adding too many screens, ask:

What information needs to be saved?
Will I use SharePoint or Dataverse?
What lists or tables do I need?
What should be a dropdown?
What should be a lookup?
Do I need attachments?
Do I need approval history?

For a request app, you might need:

List or table	What it stores
Requests	Main request information
Departments	Department names
Request Types	Dropdown options
Approval History	Approval actions and dates

For simple apps, SharePoint Lists may work fine.

For more structured apps with relationships, security roles, and more business logic, Dataverse may be a better option.

6. Write Down the Flows You Need

Most Power Apps projects eventually need Power Automate.

Even a basic app might need:

An approval email
A Teams message
A status update
A reminder
A confirmation email

I like to list the flows before building them.

Flow	What starts it	What it does
New request notification	A new request is submitted	Emails the manager
Approval update	Manager responds	Updates the request status
Reminder flow	Runs daily	Reminds managers about pending requests
Completion notice	Request is approved	Tells the employee

For each flow, ask:

What starts the flow?
What record does it update?
Who gets the email or message?
What should happen if something goes wrong?

7. Think About Permissions, Testing, and Launch

This part is not as fun as building screens, but it matters.

Before the app goes live, think through:

Can users see only their own records?
Can managers see their team’s records?
Can admins see everything?
Who can edit records?
Who can delete records?
Who will support the app after launch?

Also, have someone else test the app before calling it done.

You know where everything is because you built it. A new user may not.

Ask testers to try simple tasks:

Submit a request
Find the request
Approve or reject something
Check the status
Confirm they received a notification

If they get confused, that is useful feedback.

Helpful Resources

Here are a few resources that can help with Power Apps project planning:

Microsoft Power Apps planning module:

https://learn.microsoft.com/en-us/training/modules/plan-app-project/

Power Apps documentation:

https://learn.microsoft.com/en-us/power-apps/

Power Apps Plan Designer:

https://learn.microsoft.com/en-us/power-apps/maker/plan-designer/plan-designer

Power Platform ALM documentation:

https://learn.microsoft.com/en-us/power-platform/alm/

Power Platform Center of Excellence guidance:

https://learn.microsoft.com/en-us/power-platform/guidance/adoption/coe

Final Thoughts

Power Apps is great because you can build quickly.

But I have learned that a little planning makes the build much smoother.

You do not need to be a Power Platform expert. You do not need a perfect diagram. You do not need a giant requirements document.

You just need to slow down long enough to answer a few basic questions:

What problem am I solving?
Who is using the app?
What data do I need?
What should be automated?
Who can see or edit records?
How will I test it?
Who will support it later?

Start simple. Build the first useful version. Get feedback. Then improve it over time.

How to Debug a Blank Power Apps Gallery

Matt Hummel — Thu, 21 May 2026 01:11:21 +0000

A blank gallery in Power Apps does not always mean your app is broken. Most gallery issues come from one of these areas:

The Items property
A filter returning no records
A dropdown with no selected value
A search box filtering everything out
An empty collection
Delegation limits
Data source or permission issues

Start by Simplifying the Gallery

The first step is to strip the Items property down to just the data source:

'Project Requests'

If records show up, your connection is fine. The problem lives inside your filter logic.

Isolate the Filter

Add your filter back and watch what happens:

Filter(
    'Project Requests',
    Status.Value = "Approved"
)

If the gallery goes blank again, you know the issue is inside the filter itself — not the data source.

Handle Dropdown Filters with an "All" Option

Dropdowns with no selected value can silently filter out everything. Use an "All" fallback to prevent this:

Filter(
    'Project Requests',
    ddStatus.Selected.Value = "All" || Status.Value = ddStatus.Selected.Value
)

This way, when "All" is selected, every record passes through.

Debug Collections with a Count Label

If your gallery is backed by a collection, add a temporary label to check whether it actually loaded:

CountRows(colProjectRequests)

If that returns 0, the collection was never populated — check where Collect() or ClearCollect() is called and whether it runs on app start.

The Core Debugging Principle

Do not try to debug everything at once.

Start with the raw data source
Confirm records appear
Add each filter or condition back one step at a time

Isolating variables is how you find the real problem fast.

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?