Microsoft Fabric Apps - Simply Explained

Welcome back to another Knowledge Nugget. I'm Merco Peters from M365FM. And today we're tackling a big question. You've probably heard the buzz about Fabric Apps. People are saying, "Fabric Apps for Places Power BI." Goodbye, Power BI reports. The end of business intelligence. I've watched those videos, I've read those posts, so let me give you the straight answer, the hype is real, but you need the context. Is Fabric Apps really the end of Power BI? Let's cut through it. By the end of this episode, you'll know exactly what a Fabric app is where it fits next to Power BI and whether you should care. The answer isn't as simple as yes or no. What is a Fabric app? So let's start with the simplest definition. A Fabric app is a managed web application that runs inside Microsoft Fabric. That word "managed" is the key. It means Fabric handles the hard parts, so you don't have to. Think of it like renting a furnished apartment versus building a house from scratch. When you build a house, you're responsible for everything. The foundation, the plumbing, the electrical wiring, the permits. When you rent a furnished apartment, you walk in, the lights work, the water runs, and you just need to bring your furniture. Fabric apps is like that. Microsoft provides the backend, the servers, the database, the security, the hosting, and you just build the front end. The part people actually see and interact with. Here's the thing. Fabric apps is a new item type in Fabric workspaces. If you've used Fabric before, you've probably seen items like Lake Houses, notebooks, or Power BI reports. Fabric apps sits right alongside those. It's just another kind of thing you can create in a workspace. But instead of storing data or running transformations, it's for building applications. You get two main options. First, the data app. This connects directly to an existing Power BI semantic model. So if you've already built a data model with measures and relationships, you can plug a Fabric app right into it. Second, the blank app. This one comes with its own SQL database and you define the schema yourself. Both are useful, just for different scenarios. So why does this matter? Before Fabric apps, if you wanted to build a data-driven web application, you had to manage a lot of stuff yourself. You needed a server and API, authentication and hosting. That's a lot of moving parts. And each one is a potential point of failure. Fabric apps packages all of that into one service. And you create the app and Fabric sets up everything automatically. You get a SQL database, a GraphQL API, authentication through Microsoft Entra ID and static hosting for your front-end files, all of it, out of the box. What this means for you is simple. You can build a real working application without being a full stack developer. You don't need to know how to set up a server, configure an API gateway, or manage user sessions. Fabric handles all of that. You just need to focus on the part that matters. What your app looks like and what it does. The building blocks. Let's break down those four pieces I mentioned, because this is where you'll really understand what Fabric apps is doing behind the scenes. First up is the SQL database, the place where your app's data lives. It's a transactional database, so it handles reads and writes. You can insert new records, update existing ones, or delete things. It works exactly like a normal SQL server database. So if you've used that before, you already know the drill. The difference here is you don't have to set it up. Fabric creates it automatically when you create the app. Next is the GraphQL API. Think of this as the messenger between your apps front end and the database. When your app needs to show data, it sends a query through the API and the API fetches that data from the database and sends it back. When a user submits a form or updates a record, the API takes that data and writes it to the database. GraphQL is a modern way of building APIs. You ask for exactly the data you need, nothing more, nothing less, efficient and flexible. Then there's authentication handled by Microsoft EntraID, which used to be called Azure Active Directory. When someone tries to use your app, they have to sign in with their Microsoft Work or School account. Fabric handles the entire login process. It checks that the person is who they say they are and confirms they have permission to access the app. You don't need to build a login screen, manage passwords, or worry about security. It's all built in. Finally, static hosting. This is where your apps front end files live. The HTML, CSS, and JavaScript that make up the user interface. Fabric serves these files from a URL, so users can access the app from their browser. When you make changes, you deploy the new files and Fabric updates the hosted version automatically. Now, here's the thing. You don't need to become a developer to use this. The templates handle most of the setup. When you create a new Fabric app, you can start from a template that already has authentication wired up, the API configured, and a basic front-end structure. You just customize it. The rule magic is that these pieces work together automatically. You create the app and Fabric provisions the database, sets up the API, configures authentication, and prepares the hosting all in the background. You don't have to connect them manually or write configuration files. It just works. So those are the pieces. But how do they actually connect to the data you already have? That's what we'll cover next, how it connects to your data. So you've got this app with a database, an API, authentication, and hosting. But where does your actual data come from? Because honestly, you probably already have data sitting somewhere in Fabric. Maybe you've got a semantic model with carefully built measures. Maybe you've got data in a lake house. Fabric apps doesn't make you start from scratch. It connects to what you already have, and there are two ways to do it. Option one is the data app template. This connects your app directly to an existing Power BI semantic model. All those measures you build, all those relationships you defined, all those calculations, they're available to your app through DAX queries. Your app can show the exact same numbers as your Power BI report. But in a completely custom interface, you're not limited to Power BI's visual controls. You can build your own charts, layouts, and interactions. The data underneath is the same-governed trusted model you already have. This is powerful because you don't have to rebuild your business logic. If you've spent months getting a measure exactly right, calculating revenue the way your finance team wants it, handling currency conversions, applying the correct filters, that work carries over. Your app just queries the model and gets the right answer. And because it's the same model, your Power BI report and your Fabric app will always agree. No more, the report says one thing, but the app says another. Option two is the blank app template. This one creates its own SQL database inside the app. You define your schema using TypeScript in the code and Fabric creates the database tables for you automatically. This is the right choice when you're building an app that needs to store its own data, maybe a to-do list, an inventory tracker, a simple CRM. The data lives in the app's database and your app reads and writes to it directly. Here's something interesting. That SQL database also has a read-only analytics endpoint. Fabric automatically mirrors a copy of your operational data into one lake and that endpoint sits on top of that copy. So while your app is doing transactional work, creating orders, updating records, the analytics endpoint lets you build Power BI reports on that same data without affecting your app's performance. It's like getting a reporting layer for free. So to summarize, if you already have a semantic model, use the data app template. If you're building something new that needs its own storage, use the blank app template. Both paths lead to the same place, a working application connected to your data. Fabric apps versus Power BI. Fabric apps and Power BI aren't replacements. They're complimentary. They do different things, so you use both where they fit. Power BI is a business intelligence tool. It's built for governed reporting, ad hoc analysis, and sharing insights across your organization. When you need to slice data by region and drill into a specific product category, Power BI does that better than anything else. When your finance team leads paginated reports, Power BI has that. When executives want to ask questions in plain English, Power BI has natural language queries. It's a mature product with years of development. Fabric apps is an application development tool. It's built for custom, user, experiences on top of your data. When warehouse workers need a form to update inventory levels, that's a fabric app. When you need a dashboard with custom animations and a layout that matches your brand guidelines, that's a fabric app. When you need something that feels like a real application, not a report, that's where Fabric apps comes in. Think of it like a modern office building. Power BI is the conference room where you analyze data. You look at the numbers, explore, find insights. Fabric apps is the front desk where you interact, enter data, checkers status, complete a task, different purposes, different experiences, where Power BI shines is analysis. Cross filtering, drill through natural language queries, paginated reports. These features took years to build. Fabric apps doesn't have them yet, and it probably never will in the same way. That's not what it's for. Where Fabric apps shines is custom experiences. You control the layout completely, you can add animations, build custom navigation, create interactions that aren't possible in Power BI's canvas. And here's the key. You can write data back to the database. Power BI reports are read only. In a Fabric app, users can update records, submit forms, change data. Here's the insight that matters. The semantic model becomes the shared foundation. Both tools can use the same governed data. You build your model once and then Power BI reports and Fabric apps both pull from it. Your measures are consistent, your security rules are consistent, your data is consistent, the model becomes the single source of truth. Both tools are just different ways of interacting with it. So when you hear goodbye Power BI, what people really mean is, hello, more options. They're not saying Power BI is dead, they're saying they have another way to build on their data. And for Power BI users, here's the real takeaway. Your skills become more valuable, not less. Data modeling, DAX, understanding business logic, these are the foundation that makes Fabric apps work. Without a good semantic model, your Fabric app has nothing to connect to. The people who understand the data will be the ones building the best apps. What you can actually build? Let's make this real. What does a Fabric app actually look like in practice? What kind of things can you build with it? One common use case is an inventory management dashboard with write back. Imagine you're running a warehouse. Products come in and go out, stock levels change throughout the day. In a traditional Power BI report, you can see the data, but you can't act on it. If you notice a product is running low, you have to open a separate system to place an order. With a Fabric app, you build a dashboard where you click a button in the stock updates right there. The data flows back to the database. The next time someone opens the report, the numbers have changed. Another example is internal operational dashboards for specific teams. HR might want a tool for tracking employee onboarding. Finance might want a dashboard for expensive approvals. Logistics might want a real time view of shipments. These are things you could build with Power BI, but they'd be read only. With a Fabric app, each team gets a custom interface that matches how they actually work. Forms, buttons, status updates, and it feels like a real application, not a report. There's also rapid prototyping. This is where Fabric apps really shines. You can go from an idea to a working app in hours instead of weeks. Let's say your team needs a tool to track customer feedback. In the old world, you'd submit a request to IT, wait for a developer to become available, go through a design review, and eventually get something months later. With Fabric apps, you can build a prototype in an afternoon. It might not be perfect, but it's good enough to test with real users and get feedback. And if it works, you can polish it into a production app. Data exploration tools are another good fit. If you've got a semantic model with lots of interesting data, you can build a custom interface for exploring it. Maybe you want a dashboard that lets executives browse sales data by region with a clean layout that matches your company's branding. Power BI can do this, but you're limited to its visual controls. With a Fabric app, you control every pixel. The layout, the colors, the interactions, all custom. Let me give you a real example. One company used Fabric apps to build a real-time inventory tracker for their warehouse team. Before this, the warehouse team was working with spreadsheets that were updated once a day. By the time they saw the numbers, they were already outdated. The Fabric app connected to their SQL database showed livestock levels and let workers update quantities as items moved. It replaced a system that took weeks to build with something that took a few days. Another team built a flight tracking app. They had a SQL database with flight schedules, delays, and data assignments. The Fabric app read from that database and displayed everything in a clean interface. As new data came in, the app updated automatically. The team didn't need to manage a server or build an API. They just created the app, connected it to their database, and it worked. The key insight here is that these are apps that would have taken weeks or months to build from scratch. Now they're possible in a few days. That's the promise of Fabric apps. Not that it replaces everything you already do, but that it makes new things possible. The limitations. Now before you start planning your next big project, let's talk about the boundaries. Fabric apps is powerful, but it's not magic and it's not ready for everything just yet. The biggest thing to know is that fabric apps is still in public preview. That means things can change, features can break, and the documentation might not be complete. Microsoft is still figuring out what works. So if you build something today, you might have to rebuild it when the feature reaches general availability. That's the nature of preview software. It's great for learning, but you probably don't want to bet your entire business on it just yet. Second limitation. Authentication is limited to EntraID single sign on. The Microsoft login system for work and school accounts. You cannot add guest users, allow anonymous access, or use a custom authentication provider. This means your apps are only for internal users. You can't share them with customers or partners. If you need a customer facing dashboard, power BI embedded is still the way to go. Fabric apps is for your organization's people and only your organization's people. Third, cost. Fabric apps runs on your existing fabric capacity, but it's not free. Every query, every API call, every file served consumes capacity units or CUs. If you're on a small plan like F2, which costs about $260 a month, you need to watch your usage carefully. A few heavy queries can eat up your capacity quickly, and if you're using AI coding agents to help build your app, those costs tokens too. You can burn through a monthly budget faster than you'd expect. Fourth, no built-in support for complex, multi-step transactions or stored procedures. If your app needs to do something like charge a credit card, update inventory, and send a confirmation email as a single operation, Fabric apps doesn't handle that natively. You need to build that logic yourself or use a different tool. Fifth, consistency. When you use AI to generate your app, every prompt produces a different result. The same prompt can give you a completely different layout, different colors and different behavior. If you're building multiple apps, they might look nothing alike. You can fix this by defining a design system and being very specific in your prompts, but it takes effort. And finally, front-end development still requires some understanding of code. Even with AI help, you need to know enough to guide the process. The AI can write the code, but you need to be able to tell it what you want and recognize when it's gone wrong. If you've never written a line of JavaScript, you'll find this challenging. So what does this mean for you? Fabric apps is powerful, but it's not a silver bullet. Go in with realistic expectations. Use it for internal tools, prototypes, and apps where you control authentication. And don't abandon Power BI. It's still the right tool for governed reporting and analysis. How the pieces fit together. Let's step back and look at the whole picture. This is where the RHA moment happens. Fabric apps isn't a single product. It's a platform. It takes the data you already have in fabric, your semantic models, your SQL databases, your one-leg storage, and gives you a way to build custom experiences on top. The connection is the key. Your semantic model becomes the single source of truth. Both Power BI and your fabric apps pull from the same model. When you define a measure in that model, both your report and your app use the same calculation. When you update data in your SQL database, both your app and your Power BI report reflect the change. No more duplicating logic, no more wondering which version is correct. This is what Microsoft means when they say end to end. From data ingestion to reporting to custom applications, all in one platform. The data flows from your source systems into one-leg, gets transformed and modeled, and then surfaces through whatever tool makes sense for the job. Power BI for governed analysis, fabric apps for custom interactions, both build on the same foundation. For a beginner, the takeaway is simple. Fabric apps extends what you can do with your data. It doesn't replace what you already have. Think of it as adding a new room to a house you already live in. The foundation is the same, the plumbing and electrical are the same, but now you have a new space to use however you want. Your next steps. So where do you actually start? Let me walk you through a few concrete steps. If you have a fabric capacity, go enable the fabric apps preview in your tenant settings. It's in the admin portal under tenant settings. You'll need to flip the toggle for fabric apps and also enable the semantic model execute queries rest API without both nothing will work. Next, create a new workspace and try the blank app template. Don't worry about building anything useful yet. Just go through the process. Create the app, look at the generated files and see what gets created in your workspace. The SQL database, the API endpoint, the hosting configuration. Just seeing the structure will help you understand how it all fits together. If you already have a Power BI semantic model, try the data app template, connect it to your model and see what happens when the app reads your measures and relationships. You don't need to write any code for this, the template handles everything. Then use an AI coding agent to make small changes at a filter, a change a color, move a chart. The prompts cost tokens, but a few small experiments will teach you more than watching 10 tutorials. You'll see how the AI interprets your requests and what kind of results you get. The most important thing you can do right now is understand where fabric apps fits in your organization. Identify one use case, a small internal app that solves a real problem. Maybe it's a dashboard your team checks every morning or a form that replaces a spreadsheet. Pick something small, something you can build in a day or two and try to build it. One last thing, this is the beginning of something big. Fabric apps is in preview now, but it will mature. Getting familiar with it now means you'll be ready when it's ready for production. The people who understand this tool early will be the ones building the best solutions later. So that's the system. Fabric apps is a new way to build on your data, not a replacement for the tools you already use. Learn it, experiment with it, but don't abandon what works. Subscribe for more plain English breakdowns of Microsoft's data platform and share this with someone who's confused about the hype, it'll help them too.