Your Power Platform Trainer: J. H. Irwin
Author | Content Creator | Technology Strategist
At the end of Module 1, I asked you to bring your curiosity and that spreadsheet quietly holding your department together
I hope you brought both, because this is the module where we stop touring the workshop and start building in it. By the time you finish, you will have a free development environment of your own, a working understanding of how Power Apps thinks, and a real application running on your phone that you built yourself. Not a demo you watched. Yours.
If you missed Module 1, it maps the whole Power Platform in plain English, and it is worth ten minutes before you continue. The short version: Power Apps is Microsoft’s tool for building business applications without traditional code, and it sits on a shared foundation called Dataverse alongside its siblings for automation, analytics, websites, and AI agents. Today we go deep on this one tool, because everything else in this series builds on it.
First, Get Yourself a Workshop (It’s Free)
Before you can build anything, you need a place to build it, and Microsoft gives you one at no cost. The Power Apps Developer Plan provides your own personal environment with the full premium feature set: Dataverse, premium connectors, the works. It is meant for learning and building, not for running production apps for other people, which is exactly what we want right now. Nothing you break in your developer environment can hurt anyone.
Sign up at Microsoft’s Power Apps developer plan page (search “Power Apps Developer Plan” and it will be the first result). One honest caveat: you need a work or school Microsoft account to enroll. Personal accounts like outlook.com or gmail.com will not work. If you have a job with Microsoft 365, you almost certainly have a qualifying account already. If your employer has locked down self-service signups, or you do not have a work account at all, Microsoft offers a path to create a free developer tenant through the Microsoft 365 Developer Program, though availability of that program has tightened over the years. Most readers will be fine with the account they use at work.
Once you are enrolled, open make.powerapps.com in your browser. Check the environment picker in the top-right corner and make sure it says your name followed by “dev” or similar. That is your workshop. Everything in this series happens there, deliberately away from your organization’s shared spaces.
A Quick Tour Before We Touch Anything
The maker portal home page will greet you with a large text box inviting you to describe an app in plain language. That is Copilot, and yes, it can genuinely generate working applications from a sentence, including a newer capability called plans that can design entire multi-part solutions, tables and apps and automations together, from a description of your business problem. We will talk about when to lean on that shortly. For now, resist it. There is a reason flight schools still teach students to fly before handing them the autopilot.
Down the left side you will find the navigation that matters: Create (where new apps begin), Apps (everything you have built), Tables (your Dataverse data), and Solutions (containers for packaging work, which becomes important later in your journey but not today). Spend two minutes clicking around. Nothing here bites.
The Two Kinds of Apps, and How to Choose
Module 1 introduced canvas and model-driven apps from a distance. Up close, the difference is philosophical, and understanding it will save you from building the wrong kind of app, which is the most common early mistake I see.
A canvas app starts with a blank screen and gives you total control. You place every button, every label, every gallery exactly where you want it, the way you would arrange objects on a PowerPoint slide. The app’s behavior comes from formulas you attach to those objects. Canvas apps shine when the task is the star: a warehouse check-in screen, a field inspection form, a conference room booking tool. Anything where you can picture the ideal screen for one focused job, that is canvas territory.
A model-driven app flips the relationship. You do not design screens at all, at least not at first. You design data: tables, columns, relationships, business rules. Power Apps then generates a complete, consistent, professional interface around that data, with forms, views, dashboards, and search, all following the same design language as Dynamics 365. Model-driven apps shine when the data is the star: case management, asset tracking, anything with many related record types and people whose whole job is working those records. Recent updates have made these apps genuinely pleasant, with modern theming and Copilot built into the experience, so users can ask questions about their data in plain language.
Here is the rule of thumb I give everyone. If you find yourself sketching a screen, build canvas. If you find yourself sketching a spreadsheet with multiple related tabs, build model-driven. And if you are torn, start with your data in Dataverse either way, because a well-built table can feed both kinds of app later. Data outlives interfaces. It always has.
Power Fx: If You Can Excel, You Can App
The logic inside canvas apps is written in Power Fx, and if the word “programming” makes your shoulders tense, I have good news: you already know most of what you need. Power Fx was deliberately modeled on Excel formulas, right down to the philosophy. In Excel, when cell A1 changes, every formula referencing A1 updates instantly, without you telling it to. Power Fx works the same way. When your data changes, everything built on it recalculates. You describe what should be true, and the app keeps it true.
A few formulas will carry you a long way. Filter(Requests, Status = "New") returns only the new requests from a table called Requests. SortByColumns(Requests, "DueDate") puts them in date order. User().FullName returns the name of whoever is using the app right now, which is how one app can greet a thousand different people correctly. Navigate(DetailScreen) moves the user to another screen. And Patch() writes changes back to your data, the formula equivalent of hitting save. That handful, combined with If(), which works exactly like its Excel cousin, covers a remarkable share of real-world apps.
Now We Build: Your First Working App
Enough philosophy. We are going to build a simple team request tracker, the honest replacement for a thousand overworked spreadsheets. Follow along in your developer environment; the whole exercise takes twenty to thirty minutes.
Step one: create the table. In the maker portal, choose Tables, then create a new table named Team Request. Every Dataverse table comes with a primary text column, which will hold each request’s title. Add three more columns: Details (multiple lines of text), Status (a choice column with the options New, In Progress, and Done, with New as the default), and Due Date (a date column). Save it. You have just built a proper, secure, cloud database table, the thing that used to require a database administrator and a week of meetings.
Step two: add a few rows. Use the table’s editing grid to type in three or four sample requests, the way you would fill in a spreadsheet. Real-looking data makes the next step far more satisfying.
Step three: generate the app. From your table, choose the option to create an app. Power Apps will read your table’s structure and, in under a minute, hand you a complete working canvas app: a browse screen listing your requests, a detail screen for reading one, and an edit screen for changing or creating them. Press the play button in the upper right and use your app. Add a request. Edit one. This moment, watching software you made actually work, is the hook that catches most people permanently.
Step four: make it yours. Close the preview and look at the Studio around your app. The left panel is the tree view, listing every screen and every control on them. The center is your canvas. The right panel shows properties of whatever you have selected, and along the top runs the formula bar, Power Fx’s home. Try two changes. First, select the main gallery on the browse screen (it will have a name like RecordsGallery1), find its Items property in the formula bar, and wrap it so it reads something like SortByColumns(Filter('Team Requests', Status <> 'Status (Team Requests)'.Done), "DueDate"). Your list now hides finished work and sorts by urgency, which already beats most spreadsheets. Second, add a label to the top of the screen and set its Text property to "Welcome, " & User().FullName. Press play again and watch the app greet you by name.
Step five: publish and go mobile. Save and publish the app, then install the Power Apps mobile app on your phone, sign in with the same account, and open your creation. There is something quietly profound about holding it. Two hours ago this did not exist, and no programmer was involved, and yet here it is in your hand, storing data in a secure cloud database. Show someone. You have earned it.
About That Copilot Box
Now that you have built an app by hand, you have my blessing to use the shortcut, and I mean that sequence sincerely. Go back to the home page, describe an app in a sentence or two, and watch Copilot draft tables and screens for you. It is genuinely impressive, and for a first draft it can save real time. But you will notice something now that you would have missed before: you can read what it made. You can see where its table design is naive, where a screen needs rework, where a formula should change. AI is an extraordinary accelerant for people who understand the fundamentals and a frustrating black box for people who do not. The thirty minutes you just spent building manually is what converts you from the second group to the first, and that trade only gets more valuable as these tools grow more capable.
Three Habits to Start Now
I will close with the advice I wish someone had given me at this stage, because habits are cheap to form now and expensive to form later.
Name your controls. The Studio generates names like Label3 and Gallery1, and they seem harmless until your app has forty controls and a formula that references six of them. Rename things as you create them, using a short prefix for the type: galRequests, lblWelcome, btnSave. Six months from now, the person maintaining your app, quite possibly you, will be grateful.
Build in your developer environment, always. Your organization has a “default” environment that everyone shares, and it is the junk drawer of the Power Platform world. Real solutions deserve a deliberate home, and while you are learning, that home is the personal environment you created today.
Know that delegation is coming. Some Power Fx formulas can be executed by the server, which can search a million rows instantly, while others force your phone to download data and do the work itself, which quietly stops at a few hundred rows. This is called delegation, the Studio warns you about it with a blue underline, and it is the single most common reason a beginner’s app works perfectly in testing and misbehaves with real data. You do not need to master it today. You need only respect the blue underline when you see it, and know that we will tame it properly later in this series.
Your Homework, and What Comes Next
Before Module 3, build one more app, this time without me. Pick a small, real annoyance from your own work, something currently tracked in a spreadsheet, a notebook, or someone’s memory, and give it the treatment we used today: table, columns, generated app, two custom touches. Small and real beats ambitious and imaginary every time, because real problems teach you things sample data never will.
In Module 3, we hand your app a colleague that never sleeps. Power Automate can watch your Team Requests table and act the moment something changes: notify the right person in Teams when a request arrives, send a nudge when a due date approaches, route approvals without anyone forwarding an email. Your app collects the work. Next time, we make the work move.
Technology is changing the world. Read about it → The Augmented Life