Everyone loves to clown on Model-Driven Apps: “Old-school!” “Looks like 2008!” “Canvas does this better!” Fine. But here’s the punchline — I’ve built secure, production-ready Model-Driven apps fast, and in this video I’ll show you exactly how. By the end, you’ll see a plain Dataverse table turned into a themed, secure app with custom forms, views, a role, and even an automation — live. Subscribe to the M365.Show newsletter at m365 dot show so you don’t miss the follow-ups. Model-Driven isn’t supposed to be sexy — it’s supposed to work. Stick around for the 5-minute mark when that “boring” blank table becomes a usable form. And before we get there, let’s address why everyone insists these apps are boring in the first place. Why Everyone Thinks Model-Driven Apps Are Boring Model-Driven Apps carry a reputation problem. The common take is that they’re just old, stiff forms with no charm, no flexibility, and about as exciting as Windows XP’s Control Panel. That reputation sticks in kickoff meetings: bring up Canvas Apps and the room perks up; bring up Model-Driven and suddenly everyone needs another coffee. A lot of that comes from people who’ve only ever seen the default, grey starter app. They peek, smirk, and walk away. But judging it from that is like opening Excel, staring at the blank grid, and deciding spreadsheets are pointless—you never even tried the formulas. The criticism usually circles the same points. The interface looks dated. It’s not as customizable out of the box. Compared to the instant drag-and-drop magic in Canvas, it doesn’t grab attention. And to be fair, if your only exposure is the raw starter template, you’d assume it’s lifeless. Microsoft’s demo culture doesn’t exactly help either: Canvas is all bright colors and custom layouts, while Model-Driven gets positioned as “the serious option nobody shows off.” The flashy one is the cousin doing TikTok dances; Model-Driven is the one who shows up on time with the project plan. I’ll give you a concrete story. On one rollout I supported, the manager was sold on Canvas. The mock-ups looked slick. It impressed at first. But the moment our Dataverse schema started evolving, things got messy. Every column tweak triggered a handful of fixes across the app—dropdowns broke, formulas needed re-pointing, visibility conditions stopped working. It wasn’t catastrophic, but it was constant patching. Meanwhile, the Model-Driven build we had sitting quietly in parallel kept pace with the schema changes because the form logic was already sitting where it belonged—in Dataverse. No scrambling, no rework, just steady updates. That “boring” Honda Civic app ran quietly while the sports car prototype was in the shop. This stability isn’t about luck. In practice, when we use Model-Driven builds, the core business logic lives directly in Dataverse rather than being stretched over connectors and side scripts. That means when the schema shifts, the platform adjusts without a lot of duct tape. I’ve seen the difference firsthand. And to avoid staying too theoretical, we’ll actually attach a security role and wire up a relationship live in this demo so you can see how it behaves, not just hear me say it. Another piece the critics miss is security. In many Canvas builds, you end up writing conditions or duplicating checks in a few flows. In contrast, Model-Driven apps tie straight into Microsoft’s role-based model. In my experience, if an auditor or finance manager needs a clean division of what they can view versus what they can edit, roles handle it without me reinventing the wheel. It doesn’t look flashy, but it scales without panic. And that’s exactly why enterprise environments lean on it. Bottom line: Model-Driven isn’t trying to win design awards. It’s designed to get you to production without constant fires. People can call it dull, but dull and stable beats pretty and fragile when the business depends on it. Sure, it may not sparkle in the first five minutes, but once you push it, you start to understand the long game advantage. That’s what we’re going to put to the test. Instead of telling you it works better at scale, we’ll start from the absolute bare minimum and build forward in real time. From a single empty table, we’ll see how quickly structure, relationships, and even basic security can fall into place. And the best part is, you’ll watch the change happen right on screen. Building from Zero: The 'Before' State You open Dataverse and there’s one empty table. That’s where a lot of folks check out and dismiss Model-Driven apps. Nothing greets you—no dashboards, no forms, no quick sparkle of progress. Just a bare table with no personality. It looks like someone abandoned the setup wizard halfway, and for skeptics, that’s proof enough it’s boring. But really, this is just the launchpad. The truth is, on its own, that empty table does look lifeless. If you’ve been hanging around Canvas, you’re spoiled by the quick dopamine: drag a box, add a dropdown, and instantly it feels like something alive. Model-Driven doesn’t hand you that upfront rush. Instead, it’s designed around structure and stability. It asks: do you want something that looks busy right away, or something that’s going to hold together when business requirements shift six months from now? So let’s treat this plain starting point like a demo roadmap. Step one: add a few fields. Step two: create a relationship so tables can talk to each other. Step three: see how that instantly shapes the form without custom code. That’s enough to flip it from dead weight into a working scaffold you can keep building on. Fields are where we begin. You don’t need code, scripts, or PowerShell here. In the table designer, you drop in a text column for a name, maybe a choice column for status, maybe a lookup to another table. It’s straightforward, and the change is baked into Dataverse itself. I’ve built enough apps to know—when you define a column here, it’s consistent everywhere. You won’t be chasing 15 different dropdowns across the UI later. We’ll actually add those live in a second so you can see how quickly the form reacts. Think of it as snapping Lego bricks onto a base plate: every new field adds a piece, ready to link with the next. You can rearrange pieces without wrecking the foundation. Contrast that with Canvas, where sometimes it feels like pouring wet concrete—once it sets, you’re stuck with it unless you want to start over. The Lego model keeps things flexible without cracking the base. Now we add a relationship. Imagine linking Customers to Orders. In Dataverse, once you define that connection, the platform already knows how to behave. Relationships are treated as first-class citizens. You’re not patching formulas or fighting delegation rules. The moment you add the lookup, it flows through the app. When we set this up in the demo, watch how related records simply appear in the form—there’s your micro‑payoff. That’s the kind of instant feedback most people assume doesn’t happen in Model‑Driven apps. At this stage, it’s no longer an empty shell. You start to see the skeleton of a real business app: one table branching into another, roles you could imagine plugging in, and forms that are already becoming functional. Suddenly, it’s obvious how sales could log interactions, finance could track invoices, or managers could pull reports. Five minutes ago we had a blank placeholder; now, there’s scaffolding you can actually use. And here’s the important part that critics miss: this structure comes together without hacks or backflips. You don’t need to duct-tape flows or rewrite formulas just because a schema changed. The system is working with you instead of against you. It’s not about speed bragging rights. It’s about how reliably and cleanly the foundation grows once you start adding parts. So by the time we close out this “before” state, we’ve already gone from one lonely table to a connected framework with fields, choices, and relationships in place. When you see the first form render those related records, you realize the platform isn’t stuck in neutral. It’s already moving forward. Next, we go from skeleton to presentation. Because what everyone loves to complain about is how it looks. And that’s exactly where we’re headed. From Skeleton to App: Form, Views, and Theming When critics call Model-Driven Apps “stuck in 2008,” they’re really talking about the default look. Spin one up and you’re met with a grey interface that feels like corporate beige wall paint—functional, but forgettable. That plain start is intentional: it’s not trying to wow anyone out of the box, it’s giving you a blank workspace. Instead of dwelling on the blandness, we’ll walk through three quick moves that take the skeleton into something that feels like an actual app—forms, views, and theming. Step one is restructuring the form. Out of the box, every field gets dumped into one long column, like someone unloading all their groceries down the checkout belt with no order. Navigating that isn’t fun for your users, and it doesn’t help anyone make sense of the data. In the form designer, we can break that mess into logical sections: customer info on the left, order details on the right, and a new tab holding notes and history. Watch here as I move the contact block into a clean tab—notice how the record still renders properly and the relationships remain intact. Same data model underneath, just organized in a way that humans can actually use. Think of it like tailoring a suit off the rack; the material is the same, but once it’s adjusted, it looks and works ten times better. Step two is building out the views. The default view is a flat list that could make even the most caffeinated project manager g
