What does a successful business app look like? Colleagues recommending it to each other, approval times cut in half, and a tool so embedded in the working day that nobody remembers the old process. Power Platform specialist Nate Chamberlain builds apps like these for a living and he told Cloudwell exactly how it’s done, from the first discovery conversation to launch day and beyond.
When Nate Chamberlain describes a well-adopted business app, he talks about “a shared victory”, the moment colleagues start asking each other, “have you tried the new app?” and the whole organization, not just IT, feels ownership of the result. Get it right, he says, and the payoff is tangible: in the kind of example he gives, an approval process that once took three business days can come down to a day and a half.
Few people are better qualified to set that standard. The Kansas City-based developer and trainer has written ten books on Microsoft 365, earned the Microsoft MVP award five years running, and built a blog and YouTube following measured in the millions.
His starting point is refreshingly simple. “Discovery is just listening,” he says. “People need a chance to express themselves, instead of just starting with assumptions.” That instinct to sit down with the people who’ll use the app before going anywhere near Power Apps runs through everything that follows: how he decides whether a business needs an app at all, what good adoption looks like, and how to keep an app earning its place for years after launch.
When does a business decide it needs a Power Platform app? What’s the trigger?
Nate Chamberlain (NC): Honestly, identifying that trigger is what I deal with the most. Sometimes it comes up naturally in conversation: someone’s talking about a process and why it frustrates them, and you have an aha moment that takes the conversation deeper.
But often a team or business unit recognizes it themselves: the current process is slowing them down. Maybe a lot of data is stored in spreadsheets, or things have gotten so complex they’re losing track of the process. Or, and I think we’ve all experienced this one, emails start piling up, approvals fall through the cracks, and nobody knows whose turn it is anymore.
Who usually raises it, the business or IT?
NC: It depends on the company structure. If you’re lucky enough to have developers or Microsoft 365 folks in your IT department, that’s awesome. Some companies even have M365 people embedded in departments, like a finance team with a dedicated resource who can build their apps and manage their data.
But in a typical company, with just IT and business units, the business reaches out to IT: “I know we have Microsoft 365. I’ve read we could use Power Apps to replace this old PDF form. Can you help?” And if IT has the bandwidth, hopefully they don’t just say yes right away. They say: let’s look at that PDF, let’s go through your existing process, and see what we could do.
Is an app always the answer?
NC: No. And some of my favorite solutions come out of discovery conversations where we realize you thought you needed an app, but really a SharePoint list with the built-in forms would do the job. That saves me time as a developer, it saves the business time, and it’s easier to maintain. It’s a lot easier to modify a column in a SharePoint list than to redevelop a whole screen in a Power App.
No matter what, you’re spending money on people’s time, so we want to find the lowest possible solution, from a maintenance as well as a cost perspective.
Why build an app rather than an agent?
NC: Everybody’s going to have a different answer on this one because it’s such a hot topic. It was all over Build, and you see it everywhere on social media.
The way I see it, agents are really good for conversational, simpler transactions where there’s a decision tree: I ask the agent something, it gives me one of three responses, and based on my reply it goes down a further branch. Great for answering questions, simple workflows, routing a request to the right person.
We lean into apps when it gets more complex than that: several forms under different scenarios, conditional workflows on the back end, data validation, anything more involved and hands-on.
And things that are repeatable. I’m not going to a chat agent to request time off. I’d rather open an app, see my previous requests, check I have enough hours in my balance, and submit the form in one place, instead of having a back-and-forth conversation every single time.
Plenty of apps get built and then don’t perform. What do the underused ones have in common?
NC: Several things. The big one is that apps get built for users instead of with them. IT or a process improvement team has a grand idea, spends nine months to a year developing this complex application, pushes it out and people say, “That’s really cute, but what we were doing works better, for these reasons.” Nobody ever talked to them and got their input.
The second is that the problem we think we’re solving isn’t the real problem. We do a cut-and-replace. They were using a PDF, we put it in a Power Apps form and call it a day, without ever looking at the underlying process. So, what we shipped doesn’t help at all. It’s just a new home for the same pain points.
And the third is design. Too many clicks. Asking people for repetitive data. Honestly, in 2026 we shouldn’t have to open a form and type in our name, department, title, email, and manager. You’re already signed into Microsoft 365, we know all of that. Cut out everything we can make assumptions on and make it a painless, friction-free experience.
Before we get into the how to build, what does good adoption actually look like?
NC: It starts with process analysis, and with being open about it. Share the findings. Tell users: we heard from your feedback that this is the pain point, we’re in phase one, and here’s how we’re addressing it.
Keep providing updates and giving people opportunities for dialogue as you build. That increases your adoption chances at the end, because they were part of it, even though they weren’t putting buttons on screens.
Then, when you launch, you’re looking for people talking to each other about it. “Have you tried the new app?” They’re directing each other to it. It becomes a shared victory, not just the IT team saying “we did it,” but everybody feeling like we have this thing now.
And the real success marker? You stop hearing anybody talk about the old PDF. Nobody wants to go back. People have bookmarked the app, they use it without asking questions and you stop getting tickets about it.
Who belongs in a champions program?
NC: Usually the people who are open to change, flexible with their processes, excited about new ideas. They come about naturally. If you’re in IT, you might get a ticket one day that says, “I heard about Microsoft Foundry and I want to play with it.” That person is keeping a keen eye on every announcement from Microsoft.
But you also need the change-averse people in that champions program. They’re the ones who challenge you, question what you’re doing, and raise issues that would never have come up from your very excited people.
Walk us through your discovery process. What do you ask before you build anything?
NC: To me, discovery is just listening. It sounds fancy, but honestly, people need a chance to express themselves instead of starting with assumptions.
Say I’m partnering with finance on purchase requests. I don’t open with “we’re going to build you an app.” I say: tell me what you’re currently doing for purchase requests. Then I’m quiet. I take notes. I ask about approval conditions: is there a dollar threshold that requires CEO-level approval? After that conversation, I show them a process map of what I understand their current process to be, and we validate it together.
Then I take that map and identify how the technology stack could improve it: Power Automate, Power Apps, or maybe just that SharePoint list. I run scenarios by them with the pros and cons of each approach and ideally show them a simpler process map: this is what you’re doing, this is what you could be doing.
For me, the benchmark is always time. Say your current purchase request process takes an average of three business days start to finish, because approvals sit in inboxes and people may or may not respond. If the new process, with push notifications and reminders, cuts that to a day and a half, that’s the win.
And once you start building?
NC: It’s very iterative. At the organization level there are town halls, here’s where we’re at. Behind the scenes, I’m doing weekly touch bases with the business owners. We get together and I say: since last week, this is what I’ve been working on, here’s where the app is at. I’ve been collecting questions between meetings, clarifying anything I didn’t understand about the process.
And it gives them the chance to ask me questions, because they’re the subject matter experts of what a purchase request needs to do. They might see where we’re at and say, could we pivot slightly and address this other pain point too? Sometimes we build it in; sometimes we discover it belongs in a later version.
How do you test before rollout?
NC: Testing starts with me, because as the developer I know the things to test that other people wouldn’t think about: can I click this weird white space, and does it do anything? Really strange edge cases.
Then I pull in the business owners for the subject matter testing: put in realistic dollar thresholds, an extreme request, a very simple request, and make sure the app seeks approval from the right people under each condition. If it doesn’t go well, that’s fine, we go back and fine-tune.
Then we open it up to champions. We might put a call out across the organization for volunteers to look at the beta, and my advice to that group is always the same: please try to break it. Nothing you submit is real at this point. Make an error, find a hole, and we’ll fix it so that when we launch, it’s right.
IT leaders are security-conscious. How do you make sure a new app isn’t opening any doors?
NC: Keeping it within Microsoft 365 helps a lot to begin with. It’s when you start transmitting to other services and platforms that you need to be extra careful about what’s being sent and whether you’re violating any regulations, in the federal space especially, you’re thinking about FedRAMP, FISMA, NIST, and SCuBA controls.
But you should also have the conversations. If you’re working with sensitive data, give your CISO, or at least their team, the opportunity to evaluate your architecture: when a user submits, it goes here, these are the permissions on that library or list. And get it in writing that the security team has approved it.
Legal review depends on the business process. One of my solutions was a leave and schedule center that generated PDF agreements, like a telework agreement. A user fills out the form, their supervisor approves it, and a PDF is generated. That language is legalese: would it hold up in court? Does it follow federal guidelines? For anything like that, legal review before launch is always a good idea.
Where does Copilot fit? Does it help you build, or help users adopt?
NC: Both, actually. For me as a builder, Copilot accelerates the process. I can spend all day writing formulas in Power Apps, which is fun, but it’s much faster to give Copilot a starting formula and say: build in six conditions that handle these cases.
It also helps with error checking. I’m human and I’ll make mistakes forever, so will Copilot, to be fair, but it’s much better at catching the missing comma or misplaced semicolon that could change your conditional logic. It’s like my assistant, speeding me up.
For end users, it lowers the barrier to entry. We can surface apps through agents and Copilot so people can simply ask, in natural language: where’s the app I need for this? It removes the “which website do I go to, which button was that” problem, and makes everything you’ve built feel more approachable. That goes straight back to adoption, alongside the basics like installing the app on the Teams side rail so it’s one click away, or making it a promoted search result in Microsoft 365.
How often do these apps need updating? And who owns that after handover?
NC: The app should change with the business. If your finance team reviews and updates its policies every year, that’s your indicator to review the app every year too. Is the app still compliant with the policy? That’s always the first question.
Some apps barely need touching. For something simple like an “Ask IT” help desk app, I design it so the business owners just manage a SharePoint list of categories. The app reads that list automatically, nobody has to open Power Apps, change anything, or publish a new version.
The trickier trigger is when Microsoft changes the technology underneath you. If you’ve built an entire app ecosystem dependent on one feature, well, it’s Microsoft, so that feature could be renamed or gone the next day. Anyone using Power Apps right now has seen the message saying a control has been upgraded to a new version. Can you keep using the old control forever? Chances are not. And when modern controls replaced classic controls, the properties changed: you can’t do everything in modern that you could in classic, and vice versa. That’s a genuine challenge, and often the point where it’s worth bringing in outside help.
If a company has already built an app that’s not being used, what should they do now? Are dormant apps costing them money?
NC: The nice thing about Power Apps is that it’s included with a lot of subscriptions. If you’re on an E5, G5, or A5 plan and building basic apps, you’re already covered. Costs come in with premium connectors, per-user or per-app plans, or large data storage on the back end in Dataverse.
But the real question with an unused app is: is it solving the wrong problem? Go back to the beginning. Maybe assumptions were made and they were wrong, the app doesn’t complete the request the way people need it completed. Or it could be the user experience. If I open an app and it’s overwhelming, I’ll do whatever I can to skirt the process, probably just email the person my request.
Nate Chamberlain is a developer, trainer, and the author of ten books on Microsoft 365, including the Microsoft 365 Administration Cookbook. He’s taking a break from the conference circuit in 2026 and will be back speaking in 2027. In the meantime, you can find him at natechamberlain.com.