The PCF Blueprint: Architecture Over UI

PCF gets pitched to you as a way to make a text box look nicer. A slider instead of a number field, a calendar view instead of a boring grid. That is the pitch you hear in every demo. But that is not what it is. Everyone treats PowerApps component framework like a UI skin. They think it is something you slap on at the end to make an app look less like a form and more like a product. But the architects who actually run large power platform tenants, they do not see a skin, they see a governance layer, and that difference matters more than it sounds like it should. Because underneath the nice controls conversation, there is a real problem. Technical debt, ALM that either exists or does not. And the thing everyone calls Citizen Developer Chaos, like it is a people problem. It is not a people problem, it is a structural one. If you are the person who ends up cleaning up someone else's power platform mess, the apps nobody documented, the fields nobody explains, the forms that break the moment someone leaves the company. Hit subscribe, this episode is for you. By the end you will see PCF as the actual difference between a tenant that scales and one that quietly collapses under its own apps brawl. The lie we tell ourselves about low code. Here is the pitch everyone gets. Low code means anyone can build business analysts, ops managers, whoever. No developers required. And PCF in this pitch is just the icing. It is just a few nice controls on top of what is already easy to build. It sounds fine, it even sounds a little exciting. More people building means more problem solved, which should mean faster business value. But there is a floor assumption buried in there. The assumption is that speed of creation equals health of the system. It does not, not even close. You can have 100 apps built in a month and a tenant that is falling apart underneath them. Because building fast and building sound are two completely different things. And low code tooling was never designed to tell you which one you are doing. This is where the cost actually shows up. Technical debt research shows that when organizations ignore debt in these builds, it can cut ROI by 18 to 29%. That is not a hypothetical drag on productivity. That is a real number tied to real remediation work later. That work would not exist if governance had been part of the build from day one. So who is actually at fault here? This is where most conversations go wrong. Citizen developers are not the risk. A business analyst dragging a field onto a form is not what causes a tenant to buckle. Ungoverned components are the risk. Think about the difference. A citizen developer building inside a system that has approved patterns, versioned controls, and clear ownership. That is the system working exactly as intended. A citizen developer building inside a vacuum. Where every app invents its own logic, its own validation and its own visual language. That is not citizen development. That is just structural drift with a friendly name. And this is where PCF actually earns its place in the conversation. Not as decoration, but as the thing that closes that vacuum. Because a properly built PCF component is not a suggestion. It is not a style guide somebody wrote and nobody reads. The moment it gets packaged and deployed, it becomes an enforcement mechanism. Every app that uses it inherits the same validation, the same behavior and the same guardrails. That happens whether the person building that app knows it or not. That is the reframe this whole episode is built around. PCF is not decoration. It is the enforcement layer. And once you see it that way, you start asking a completely different set of questions about how your tenant is actually built. What PCF actually is structurally. Forget the marketing for a second. Because that's where the confusion starts. PCF is a code component framework. That's it. It is a way to write typescript, package it and plug it into three specific places. Model driven apps, canvas apps and custom pages. That is the entire surface area. It isn't a design tool or a theme engine. It's a framework for building components that get deployed like software. Because that's what they are. When you actually build one of these, you pick one of two templates. This distinction matters more than people realize. The first is a field control. It's bound to one value. One control replaces one field on a form. Think of it as a scope swap. Whatever is sitting in that number field or text field, you're replacing it with your own logic. But only for that single value. The second is a data set control. It's bound to a whole grid. This is what replaces subgrids views and entire lists of records. Instead of touching one value, you're changing how a set of rows gets displayed and sorted across every form using that view. Two templates. Two very different blast radiuses. This isn't a UI detail. It's an architecture decision baked into the tool itself. But here's the part that actually matters for your strategy. Once you build something as a component, it stops being a simple page tweak. It becomes a governed, versioned artifact. It has a manifest. It has a version number that you have to increment before changes even take effect. It gets packaged into a solution and tracked like any other piece of deployable software. Compare that to someone editing a form directly. They drag a label around. They tweak a formula in place. There is no version history on that. There is no artifact. There is just a form that looks different today than it did yesterday. There is no record of why. That's the shift. A component isn't a decoration you add to a page. It is a thing that exists independently of the page with its own life cycle that the page simply references. It is just as important to know where PCF doesn't run. That boundary shapes your architecture. PCF does not run in Power BI. It does not run in Power Automate because there is no UI surface to attach it to. And it does not run on premise. This is a cloud only capability tied to the modern unified interface. Not the legacy web client from before 2016. That boundary isn't trivia. If you're designing a solution that spans Power BI dashboards and Power Automate flows, you need to know that your governed component strategy only covers the apps. Not the reports, not the automations. All of this sounds technical. Templates, manifests, and runtime boundaries. But the implication underneath is entirely executive. Because what you're really deciding when you choose PCF over a one-off customization is whether that functionality lives inside a control system or outside of one. That isn't a developer's decision to make alone. It's an architecture decision. And it determines whether your tenant, six months from now, has a handful of known components. Or a few hundred untraceable page tweaks that nobody can explain. The governance vacuum nobody talks about. Picture a typical mid-size org running power platform for three or four years. Not a huge enterprise, not a startup. Just a normal company that adopted low code because it worked. They have somewhere between 200 and 500 canvas apps. Nobody actually knows the exact number. And that's the first sign of the problem. There is no inventory. There is no single place that says, "These are the apps we have. This is what they touch and this is who built them." There is no ownership map either. Half the apps were built by someone who left 18 months ago. The other half were built by people who have forgotten what their own formulas do. This isn't a hypothetical. This is the default state of power platform at scale. Environments multiply because it's easy to spin one up and nobody ever tears them down. Apps multiply because building is fast and nobody is tracking what already exists. You end up with duplication everywhere. Five different versions of the same expense approval app. Each built by a different team that didn't know the others existed. This is where classic web resources made a bad situation worse. Back in the JavaScript and HTML era, those things were iframe-based. They ran in their own little sandboxed bubble. Invisible to the platform tooling meant to track solution contents. A web resource didn't have a life cycle. It didn't have a version number that meant anything. They just sat there, referenced by a form, until someone opened the code to reverse engineer it. You couldn't inventory a web resource the way you can inventory a proper component. You couldn't ask the platform what depends on this and get a real answer. It existed in a blind spot by design. So what happens in an environment like that? The vacuum doesn't stay empty. It gets filled, just not on purpose. Someone needs a custom drop-down behavior so they write a web resource. Someone else needs the same thing three months later. Doesn't know the first one exists and writes their own version. A third person copies the second one, tweaks it slightly and ships it into a different app. None of this is malicious. It's just what happens when there is no visibility and no catalog. And it holds together, right up until it doesn't. Some updates are shared field and three apps break that nobody realized were touching that field. Someone leaves the company and their web resource becomes untouchable because nobody else understands the code and there is no documentation. The failure always shows up in production, never earlier because there is nothing in the structure to surface the problem sooner. That's the gap. It isn't a people problem or a training problem. It is a structural absence of inventory, ownership and life cycle and that gap, the exact shape of it, is what PCF was built to close. PCF has enforcement by design. That gap has a name now, at least for the people watching where power platform governance is heading in 2026. The shift is called enforcement by design. It's worth sitting with that phrase for a second because it's doing a lot of work. Enforcement by design means the rules aren't written down in a document, hoping people read them. There is no policy PDF sitting in a SharePoint folder that nobody opens. There are no onboarding slides that say please follow governance standards. Only to be ignored the moment a deadline hits. Enforcement by design means the rules are built into the tool itself. Having them isn't a choice, it's just what happens when you use the platform. And that's exactly what a PCF component does, the moment it gets packaged into a solution. The mechanism is simpler than it sounds. The instant you take a component and reference it inside a solution. It stops being loose code sitting in a project folder, it becomes a government dependency. The platform now knows it exists, it knows what solution it belongs to, it knows what version it's on, that knowledge isn't optional metadata you have to configure. It's just there, automatically. Because that's how the packaging works. Once it's a government dependency. It inherits a whole set of behaviors without anyone lifting a finger to set them up. First, you get versioning. Every component carries a version number in its manifest. That number has to increment before change takes effect. You can't silently override a component the way you could silently edit a page. Second, you get promotion rules. A component inside a solution moves through the same path as everything else that goes from dev to test to production. It doesn't get hand-carried into an environment by whoever happened to build it. Third, you get rollback paths. If a new version breaks something. There's an actual previous version to fall back to, but the old one didn't get erased. It got superseded. None of that existed with the old model. A JavaScript web resource had no version discipline built in. You could edit it in place, re-publish it, and the old behavior was just gone. There was no promotion path either. People would build directly in what was functionally a production environment, because nothing was stopping them. And rollback, there was nothing to roll back to. The old code wasn't preserved anywhere unless someone kept a manual backup. And let's be honest, that almost never happened. This isn't abstract. Let's look at how this actually plays out. A team needs something fixed fast. Maybe a form field isn't validating correctly and there's a deadline. Someone writes a quick JavaScript web resource. Tests it in the moment. And ships it. It works. Everyone moves on. Six months later, someone else is trying to figure out why a form is behaving strangely. They open it up and find that web resource sitting there. But there's no way to answer the basic questions. Who wrote this? What version is it? What else does it touch? There's no audit trail, because a web resource was never designed to leave one. Now run that same scenario with a PCF component instead. Someone builds the fix. They package it into a solution and push a version increment. Six months later, when someone opens that same solution. The component is right there with its version history intact. You can see when it was deployed. You can see what changed between versions and because it's tracked as a dependency, you can see exactly which forms an apps reference it. Same emergency, same six month gap. But the outcome is completely different because one of these was built to leave a trail and the other one wasn't. The solution layer, why packaging changes everything. We've talked about what happens once a component is packaged. Now let's talk about the thing doing the packaging. Most people hear the word solution and think it's just a dynamics-flavored term for a folder. It isn't. Solutions are the delivery mechanism for PCF. Full stop, they aren't a dynamics concept borrowed for convenience. They are the actual pipe that moves a component from your machine to a real environment where real people use it. In practice, this changes everything. You write your TypeScript, you build it locally, you test it in a harness. One of that matters yet in a governance sense because none of it is deployed anywhere real. The moment it changes is the moment you reference that component inside a solution and push it. That single act flips a switch. The component stops being a folder of code on your laptop. It starts being a tracked dependency inside a system that knows it exists. Think about what a tracked dependency actually buys you. Once a component is in a solution, the platform knows which solution it lives in, what else is packaged alongside it and what depends on it. You don't set that up. It's just what a solution is. It's just that to a page decoration. Some tweak someone made directly on a form, no packaging, no reference, nothing tracking it. A page decoration disappears from institutional memory, the second the person who made it stops explaining it in Slack. A tracked dependency doesn't have that problem because it's not memory dependent, it's structured dependent. Inside the solution layer, there's a distinction that matters more than most teams treat it. Managed versus unmanaged. An unmanaged solution is your working state. It's editable, it's flexible, it's where you're still figuring things out. A managed solution is locked, you can't casually edit its contents in the target environment. And that's not a limitation, that's the entire point. Production environments should run managed solutions because production isn't where you want components changed by whoever happens to click into it. The unmanaged to manage distinction is really a discipline distinction. It draws a hard line between this is still being shaped and this is deployed and stable. Skipping that line is exactly how components end up getting silently altered in place as nobody is supposed to touch. And this is where the connection to ALM stops being abstract. If your component only exists as an unmanaged blob, you push straight into an environment, you don't have ALM, you have a habit. Real application lifecycle management means that component moves through a path. It starts in dev where it's built and broken and fixed, then it goes to test where it gets validated against something other than your own assumptions. Finally, it reaches production in production, it reaches real users, packaged as managed, locked down, and traceable. The promotion path isn't the best practice you can skip when you're busy. Once a component lives inside a solution, the promotion path is structural. The solution mechanism basically forces the question, which environment is this actually ready for? That's what's happening underneath all of this. Governance by architecture stops being a phrase in a slide deck, the moment packaging enters the picture. Because packaging turns intention into a pipeline, you don't have to trust that someone will follow the rules. The solution layer just doesn't let you skip the steps. Field controls, the smallest unit of governance. Zoom all the way down to the smallest possible unit. Everything we've said about solutions and packaging still applies here, even at this tiny scale, and that surprises people. A field control is the simplest thing PCF does. It's one control bound to one value, replacing one native field on a form. That is it, there is no grid, no dataset, no list of records. You are touching a single value, the same way you would touch a single cell in a spreadsheet. Nothing about that sounds like it should matter much, it's just one field. But here's the thing, most people get wrong at exactly this scale. You can hear at the smallest possible unit of PCF you aren't making a cosmetic choice. You are making an architectural one. The size of the change has nothing to do with the size of its consequences. Let's make that concrete. Say you have a whole number field, someone decides it would be nicer as a slider. Drag left, drag right, and pick your value visually instead of typing a number. This sounds like exactly the kind of thing PCF gets marketed for. But it's the nice controls pitch, except that is not what is actually happening under the surface. A whole number field left alone will technically accept any integer you type into it. A slider constrains that. It has a minimum. It has a maximum. It has a step interval. The moment you replace that field with a slider, you aren't just predefined data entry. You are constraining how data enters your system in the first place. Someone can no longer type 4000 into a field that was only ever meant to hold values between zero and 100. You have closed off an entire category of bad input. And you didn't do it by writing a validation rule that runs after the fact. You did it by removing the possibility at the point of entry. That is a data integrity decision wearing a UI costume. Once you see it that way, you can't really unsee it. And here's the part that actually compounds over time. That validation logic doesn't live in a form anymore. It doesn't live in some business rule that has to be recreated on every screen that uses this field. It lives in the code of the control itself, which means it gets reviewed once when the component is built and packaged. Then it gets applied everywhere that control is used automatically without anyone reimplementing it. Every form, every app in every table, it is bound to inherit the exact same constraint, the same range, the same behavior. Nobody has to remember to enforce it a second time compared that to the alternative. Every team writes their own client-side validation slightly differently on every form that needs it, some catch the edge case and some do not. Some remember the maximum while others forget it entirely. A field control removes that inconsistency by design, not by policy. And if a single field carries this much architectural weight, it is worth asking what happens when you stop binding to one value, what happens when you start binding to an entire set of records. Instead, that is a different scale of decision entirely. And it is where most organizations actually lose control of their tenant. Data set controls governing at scale. Take that same idea and stretch it across an entire set of records instead of a single value. That is a data set control, instead of binding to a whole number field or a text field, you are binding to grids, views and subgrids. Anything that displays multiple rows at once, it is the same mechanism as a field control, but at a completely different scale. And this is where organizations actually lose control of their tenant. It doesn't happen with field controls. Nobody notices a slider getting out of hand. It happens here with grids because grids are where every team ends up building its own version of the same thing. Here is what that looks like in practice. One team needs to show related records on a canvas app screen so they build a gallery, they add filters, sorting and some conditional formatting to highlight overdue items. It works fine. A different team in a different department needs almost the exact same thing three months later. They don't know the first gallery exists, so they build their own slightly different filter logic, slightly different sort order. It is the same basic idea implemented from scratch all over again. You can apply that by every business unit that has ever needed to show a list of records with some custom behavior. You end up with dozens of galleries doing roughly the same job. None of them are consistent with each other. None of them share a single line of logic. That isn't a hypothetical pattern. That is just what happens when there is no shared component, and building your own is the path of least resistance. Nobody is doing anything wrong. They are just solving the same problem in isolation over and over because there is nothing stopping them. There is nothing steering them towards something that already exists. A single dataset control changes that math entirely. You build the grid once, you add the sorting, the filtering, and the conditional formatting it needs, then you deploy it. That one control can now replace every one of those ad hoc gallery implementations. Because it isn't tied to a specific app or a specific team, it is a component sitting in a solution available anywhere, and that is really the reuse argument in its purest form. Build once, then bind it to any table in any form across the entire tenant. It doesn't matter if one team is showing contacts in another is showing service tickets. The underlying grid behavior, the sort logic, and the display rules all come from the same source. You are not rebuilding the wheel for every table you happen to be working with that week. Here are the stakes laid out plainly. With one dataset control governing this behavior, you have one thing to maintain. You have one place to fix a bug. You have one place to add a feature, and every app using that control gets the improvement automatically. Without it, you have 50 divergent implementations. Each has its own quirks. Each is maintained by whoever happens to remember they built it. Each one is a separate fire waiting to happen when something changes upstream. But all 50 of them depend on slightly differently. That isn't just a maintenance inconvenience. That is the difference between a tenant with one grid to govern and a tenant with 50 grids. Nobody fully understands anymore. The performance argument executives actually care about. Performance usually gets treated like a footnote, something for developers to worry about in a dark room. But in reality, it's a governance issue. Treating it as anything less is how organizations missed the point. Here is the number you need to know. The CF components load 50 to 70% faster than legacy HTML web resources. They also use less memory. This isn't a small change you need to stop watch to see. It is the difference between an app that feels instant and one that makes people sit in wait. Wondering if the screen is frozen. The gap exists because of how the code actually runs. A classic web resource sits inside an iframe. Think of it as a separate bubble, a tiny sandbox that is totally cut off from the page around it. Every time that iframe loads, you pay a tax. You are loading a separate document and a separate rendering context. It is extra overhead just to exist. A PCF component doesn't pay that tax. It shares the same rendering context as everything else on the page. It integrates directly into the platform pipeline instead of being bolted onto the side. There is no iframe boundary to cross. And no second document quietly loading in the background while the user waits. That is the mechanical reason. But here is the shift. Faster apps are not just a nice to have feature. You don't just mention them in a release note and move on. Performance translates directly into the report's leadership actually looks at. Support tickets go down. The app is slow is the most common complaint any power platform team here. And it is rarely about the data. It is almost always about the rendering. Adoption goes up. People quietly abandon tools that feel sluggish. Even if they never file a formal complaint. They just stop opening the app. Eventually someone asks why the usage numbers are dropping. And the answer traces back to a load time that nobody bothered to measure. When you argue for governed PCF components over legacy resources, you aren't making an aesthetic case. You are making a case about ticket volume and adoption curves. Those are the numbers that get budgets approved. But I need to slow down here. Because performance cuts both ways, this is where most implementations go sideways. Everything I just described happens when a PCF component is built well. That 50% to 70% gain isn't automatic, just because you chose the framework. It is a ceiling, not a guarantee. The moment you assume the framework does the work for you, you've missed the part that requires discipline. Where PCF performance breaks down, a badly built PCF control can be slower than the native field it replaced. Not just unoptimized, slower, worse. It becomes the exact opposite of what PCF is supposed to deliver. That should stop you for a second. It means choosing PCF is not a performance decision on its own. It is a starting point. It can go in either direction depending entirely on what happens inside the code. So let's walk through how this breaks. The failure modes are very specific. First, bloated bundles. Every PCF component ships a package of code to the browser. If that package is heavy, the user pays for it on every single load. A control meant to show one simple field can end up weighing more than the entire form it sits on. Second, unnecessary libraries. This usually starts with good intentions. A developer needs one function from a charting library, so they import the whole thing. When you multiply that across five components on one form, you have five copies of overlapping code loading at once. None of them share resources. All of them add to the initial load time while the user sits there waiting. Third, constant re-renders. If a component redraws itself every time a tiny thing changes, it feels laggy. The moment someone starts typing or clicking, the interface stutters. That isn't a data problem. It is a code problem, and it stays invisible until someone actually interacts with the thing. None of this is exotic. These are the same mistakes people make in general web development. Because that is what this is now. Native controls are the performance baseline for a reason. Microsoft spent years optimizing those out of the box fields and grids. They aren't fast by accident. They are fast because of massive engineering effort. A PCF control does not inherit that work automatically. It starts from zero. It only matches that baseline if the person building it puts in the same level of discipline. This is the architectural point. A PCF control isn't just a power platform customization anymore. It is a piece of front-end engineering. Bundlesize, re-render logic dependency choices. All of it needs the same rigor you would expect from a production web app. Because that is what is happening every time you deploy. This is where the conversation has to go next. If a component can be this good or this bad-based purely on how it was built, then governance cannot stop at environments. It has to include a review process for the components themselves before they ever reach the catalog. Otherwise, you aren't governing quality. You are just governing where the bad performance gets deployed. The hybrid model, standard controls versus PCF. If a component can break this easily, you might think the answer is caution. And it is. But not the way most people apply it. The decision framework here is simple to state. It's just harder to follow when you're under deadline pressure. Standard controls first. PCF only where there is a structural gap. Not PCF because it looks nicer. Not PCF because someone on the team wants to try building one, a structural gap. Something standard controls genuinely cannot do. Not something they do adequately but less impressively. So what actually qualifies as a gap, three things. And we have to name them precisely. Because vague criteria are how this framework gets abused within a month. First, complex visualization. Think of a gant chart or a custom map view. No combination of native fields and galleries gets you there. Second, high traffic screens. The handful of forms or apps that hundreds of people touch every day. On that scale, even a small usability improvement pays for itself. Third, reusable patterns across many apps. The kind of thing we saw with data set controls, where one build replaces dozens of team by team reinventions. Notice what is missing from that list. It would look better. That is not a criterion. That is a preference. And preferences do not justify the maintenance burden a custom component carries for the rest of its life. But here is the problem. The mistake that happens constantly, someone takes a simple text input, a field that does exactly what a native text field already does and replaces it with a heavy custom control. Maybe it has a styling flourish. Maybe it does something the native field already handled with a simple formula. That is not a governance win. It is a governance failure. Dressed up as an improvement. Now you have a component to version. You have to review it. You have to maintain it. You have to explain it to the next person who opens that form. And it is buying you nothing that a native field wasn't already giving you for free. Every PCF component you deploy is a promise. A promise that someone will maintain it. That its performance will be watched. That its dependencies won't quietly rot. You don't make that promise for a text box. You make it for the things that actually earn the weight. Which raises the obvious next question. If PCF only belongs in the tenant for genuine structural gaps. How does anyone actually know what's already been built? What's already approved? What still needs a fresh component versus a native field? You can't keep that in someone's head. You can't rely on institutional memory because we already saw what happens to that memory. The moment the person carrying it leaves. That is where the idea of a catalog comes in. Not a folder of code samples. A catalog in the governance sense is a documented and versioned list of the components and organization has actually approved for use. It says what they do. It says what they are for. It shows where the line sits between use this and build your own. It is an artifact. The same way a solution is an artifact. Something that exists independent of any one person's memory. And once that catalog exists, it stops being a nice reference document. It starts being the actual organizing principle behind how an architecture team runs its entire component strategy. Building the component catalog. Here is what a mature organization actually maintains. And it is less exciting than it sounds, not a wiki page someone updated once, not a channel in teams where people occasionally post. Hey, did anyone already build this? A documented versioned library of approved components with a real record of what each one does, what version it is on, and what it is meant to replace that is the catalog. It is a list. But it is a governed list, which is a completely different thing from a list someone made once and forgot about, because in reality, this matters more than any single control you could point to. A catalog is what turns PCF from a developer hobby into an enterprise asset. Without one, every well-built component is still just one person's good work. It's sitting somewhere. It's known only to whoever happened to be in the room when it got built with a catalog. That same component becomes something the whole organization can find. They can trust it. They can reuse it without needing to ask around first. That is the difference between a nice thing someone made and an actual piece of infrastructure. And the economics behind this are worth stating plainly. They are not subtle as we walked through earlier. One well-built dataset grid can replace 50 ad hoc implementations scattered across business units. Implementation is built in isolation by teams that didn't know the others existed. A catalog is the only mechanism that makes that replacement actually happen. It is not enough for the good grid to exist somewhere. People have to know it exists. They have to know it is approved. They have to know where to find it. Otherwise, you have just added a 51st implementation to the pile. Better than the rest. Sure. But still invisible to everyone who isn't already in the loop. Now here's the question that gets skipped constantly. And it is the one that decides whether any of this actually holds. Someone has to own this catalog, not the team in some vague collective sense, a person or a small group, whose actual job includes deciding what gets added, what gets deprecated, and what gets rejected when it doesn't meet the bar. Without that ownership. A catalog doesn't stay a catalog for long. It decays exactly the way the original's brawl decayed, quietly, through neglect. Until nobody is sure if the thing listed in there is even the current version anymore, because a catalog is not a one-time deliverable. It is a living structure, and living structures need someone accountable for keeping them alive. The moment ownership goes unclear, entries go stale, deprecated components, stay listed as current, and the whole document slides back into being exactly the kind of unreliable reference the original governance vacuum was full of. Which brings up the real question underneath ownership. How does a catalog actually stay alive? Mechanically, day to day, version to version? That is not a policy question. That is an ALM question. And it is the machinery that keeps this whole thing from decaying the moment everyone gets busy again. I'll miss the backbone, not an afterthought. Let's state this plainly, because it's easy to not along and still miss the point. PCF without ALM is just custom code with extra steps. That isn't a critique of the framework itself. It's a description of what happens when a team treats PCF as a coding exercise instead of a delivery discipline. You can write a beautiful component. It can be structurally sound, performant, and well within scope. But if that code gets pushed straight into an environment with no process behind it, you haven't actually gained anything. You're just repeating the old, undisciplined web resource habits we spent the first half of this episode taking apart. You've simply written the same messy deployment in a more modern language. So what does a real pipeline actually look like? It starts with source control. Not a folder on a laptop, not a zip file, emailed around when someone needs the latest version. The code lives in a repository with a full history. Which means you can see exactly what changed and who changed it. From there, the power platform CLI takes over. This is the same tool we used earlier for initializing projects and pushing solutions, but now it isn't a manual step someone runs when they feel like it. It's part of a defined sequence. Build validation comes next. This is an actual check to ensure the component compiles cleanly and doesn't break on the way out the door before it ever gets near a real environment. Only after those checks do you push to an environment. Even then, the code moves through the dev test production path we already established. Other than landing in front of users just because someone was in a hurry. There is a reason this sequence matters beyond just being tidy. This looks more like software engineering than app building. That isn't an accident. That's the entire point. Power platform was sold on the promise that anyone could build. That promise is still true for a canvas app screen or a simple flow. But it stops being true the moment you're writing TypeScript, packaging it into a manifest, and deploying it to production forms that hundreds of people touch. At that point, you aren't app-building anymore. You're doing front-end engineering that happens to live inside power platform. And it needs to be treated with the same seriousness as any other engineering discipline. Inside that pipeline, one discipline must be non-negotiable, versioning. Every manifest carries a version number. That number has to increment before every single solution push. This isn't bureaucratic box checking. It's the only thing standing between a controlled update and a silent override. Without that increment, a new push can replace a component in place, leaving no distinction between what was there yesterday and what is there now. With it, every change is traceable. Every rollback has something real to roll back to. Nobody is left guessing whether the behavior they see today matches what shipped last month. That's the backbone. Source control, CLI-driven builds, validation, and versioned pushes. You move through defined environments instead of skipping straight to production. But none of this holds together if the environments underneath aren't built to support it. A pipeline can be flawless on paper and still fail the moment it runs against an environment strategy that was never designed for this kind of discipline. Environment strategy as architecture. Here is the piece that's easy to skip. Right up until it's the reason everything falls apart. Managed environments aren't just a feature you turn on because Microsoft recommends it in the best practices, doc. They are the container that makes this entire process possible. Without them, your source control and versioned manifests have nowhere real to land. You can have the cleanest ALM process on paper, but it means nothing if the environments you're pushing into don't enforce any boundaries of their own. Think about what a managed environment actually does. It's the tool that lets an organization say, with confidence, that an environment has rules that apply to everyone, sharing limits, data policies, and make-up permissions all sit at the environment level. This means a PCF component doesn't just get governance from being in a solution. It inherits governance from the environment where it lives. It's two layers reinforcing each other. Instead of one layer hoping the other one shows up. There is a specific path the component should move through before it ever touches a real user. Dev comes first. This is where things get built and broken without any risk because nothing in dev is production. Test comes second. This is where the component is validated against something other than the assumptions of the person who wrote it. Ideally, this happens with someone who wasn't even in the room when the code was written. And only then do you move to production. Where the code finally reaches the people who depend on it every day. That isn't a suggestion. That is the shape the whole pipeline is built around. Skipping a step doesn't make the pipeline faster. It just makes the failure show up later in front of more people. And that path gets skipped, you hit the default failure mode, someone builds a control and tests it in their personal sandbox. They feel good about how it behaves so they push it straight into a shared solution that other apps already depend on. There is no test stage. There is no second set of eyes. It's just a jump from work on my machine to live in front of the business. That gap is exactly where the problems we've covered. The bloated bundles, the re-render issues and the silent overrides actually reach your users instead of getting caught somewhere safe. This isn't optional anymore. Getting into 2026, environment segmentation research is very blunt about this. Separating environments by purpose with defined promotion paths is the default expectation for any organization running power platform at scale. It isn't a luxury for mature teams. The organization still treating dev, test and production as one blurry space aren't just behind on a nice to have feature. They are behind on the baseline once that environment path is actually solid. Dev test prod. Each one enforcing its own boundaries. The conversation naturally moves somewhere else. It stops being about where components are allowed to live. It starts being about who is actually allowed to build them in the first place. The citizen developer isn't the problem. Who is allowed to build here? That question usually comes wrapped in a complaint and it is worth pulling that complaint apart before you accept it. The complaint goes something like this. Citizen developers create chaos. If you give business users too much access, you end up with apps brawl and broken forms. Nobody knows what is live. That diagnosis feels reasonable. But in reality, it is wrong. And it is worth being direct about why. Chaos does not come from non-developers having access. It comes from missing guardrails. Those are two completely different problems and they call for two completely different fixes. If the diagnosis is too many people can build things, the fix is restricting access. You lock down who gets to touch the platform at all. But if the diagnosis is, there is nothing steering what gets built, the fix is guardrails. You need catalogs, environment paths and review processes. You need the structure we have spent, this entire episode, walking through, blame the person and you shrink the platform, blame the missing structure and you fix the actual problem. You do this without giving up any of the reach that made low code worth adopting in the first place. This is exactly where the federated governance model earns its place. A central team defines the components and the rules. They own the catalog. They own the environment strategy. They own the review process for what gets approved. Business units do not get told to figure out governance on their own. They also do not get told to wait for IT to build every single screen. They bolt within the structure the central team already put in place. That is the whole model in one sentence, rules from the center, building from everywhere else. Picture what that actually looks like on a given afternoon. A business analyst needs to show a filtered list of accounts on a form. This is someone who has never written a line of typescript and never will. They open the component picker, find the govern dataset grid already sitting in the catalog and drag it onto their form. Done. There is no custom gallery logic. There are no rebuilt filter conditions. There is no 51st version of something that already exists 50 times. It is not a risk event that is not the moment governance failed. That is the system working exactly the way it was designed to work because the hard part the part that requires engineering discipline already happened upstream. It happened before that analyst ever opened the form so the diagnosis holds. The risk was never that a business analyst could build something. The risk was ever letting them build without anything approved to build with. But naming a model does not actually run itself. Someone has to be the central team. Someone has to own the catalog, sign off on what gets added and decide what gets deprecated. A federated model without a clear owner is just a diagram. And diagrams do not stop chaos. That ownership question is exactly where this conversation has to go next. Because it lands squarely on the one role that is supposed to make all of this real. The Architects new job description. That ownership question lands on a role that has been quietly changing shape for years. Power platform Architect used to mean the person who designed the app. They picked the data model. Maybe they reviewed a form layout before it shipped. In this model that job description is mostly wrong now. Not obsolete, wrong. It is describing work that has become a minority of what the role actually needs to do. Here is the split. Stated as bluntly as it deserves. Something like 70% of the job is now policy, catalog and pipeline design. The Architect decides what goes in the catalog and what gets rejected. They define the environment path a component has to move through. They set the review bar for what counts as production ready code. And they write that bar down somewhere other than in their own head. Screen building, the thing the title used to mean almost entirely, is now the smaller slice. Somebody still has to build the flagship components, sure. But the job stopped being mostly about building. The moment governance became the thing standing between the tenant that scales and one that doesn't. That split creates a skill gap most organizations have not priced in yet. An Architect who thinks like an app builder asks if the screen works. An Architect who thinks like a platform engineer asks what happens to every other app if this component breaks and they want to know how we find out before it happens. Those are different instincts. They are built from different experience. One who has spent a career configuring forms does not automatically know how to evaluate a build pipeline. They do not naturally reason about blast radius across a hundred consuming apps. That is not a knock on anyone's ability. It is just a real gap between the skills the old title required and the skills this version of the role actually needs. Organizations that do not name that gap out loud end up with Architects still doing 2019's job. Meanwhile, 2026's problems pile up around them. Now inside that policy and catalog work sits the piece that actually matters most day-to-day. Review responsibility. Every new PCF component anyone proposes is a candidate for the catalog. This is true whether the person building it thinks of it that way or not, which means somebody has to actually look at it before it gets in. This is not a rubber stamp. It is a real gatekeeping function. Does it meet the performance bar we walked through earlier? Does it duplicate something already approved? Does it introduce a dependency nobody has vetted? That review is where the catalog either stays trustworthy or slowly fills with components nobody is confident in anymore. But here is the limit of that gatekeeping. And it is worth naming honestly. A review process only works on things the architect can actually see. You can gatekeep the front door all day but it does not help if components are getting deployed through side doors. Nobody is watching. Forms get customized directly. Solutions get pushed without going through the catalog process at all. Gatekeeping assumes visibility. Without it you are reviewing a fraction of what is actually running in the tenant and calling it governance. Which is exactly the problem that has to get solved next. Because right now most organizations genuinely do not know what is running where. Every auditability and the cost of not knowing. Here is the blunt problem. Ask most organizations a simple question. Which apps use which components? Who actually owns them? Then watch what happens. Nobody has a clean answer. It is not because people are hiding something. It is because nobody ever built the system to answer it. There is no single list. There is only tribal knowledge scattered across whoever happened to build each piece. And half of those people have moved teams. They changed roles. Or they left the company entirely. The information technically exists somewhere. Spread across a hundred different memories. Which means for practical purposes it does not exist at all. This is exactly why an architect's gatekeeping hits a ceiling. You cannot review what you cannot see. And right now most tenants are running components that nobody is tracking. The research on governance is even blunter. Visibility is becoming a baseline expectation. It is not a nice extra for teams with time to spare. That is the shift you need to sit with. Inventory used to be something a mature team eventually got around to. Now it is table stakes. It is the same way source control became a requirement. It is no longer an optional best practice. If you cannot produce a list of what is deployed and who is responsible for it. You are not just behind. You are missing a baseline requirement for the modern enterprise. Now compare that to what a packaged PCF component gives you. You get it by default. Without building extra tools. You know who built it. You know what version it is on. You know where it is deployed. Across which solutions. Into which environments. That is not a report someone has to manually assemble. It is a direct consequence of the packaging discipline. The manifest versioning. The solution referencing. The environment promotion path. Every one of those steps leaves a trace and those traces add up to an audit trail. Whether you deliberately designed it to be one or not. Set that against the web resource era. The contrast is not subtle. A JavaScript web resource had none of that. No required version increment. No solution dependency forcing it to declare where it lived. It could sit inside a form quietly doing its job. The only record of who built it was a comment in the code. If the developer even bothered to leave one. Ask who owns it two years later. The honest answer is usually a shrug that gap between visibility and invisibility does not stay theoretical. It becomes urgent at one specific moment. The second something needs to change. As long as nothing is changing, nobody notices what they do not know. But a component review. A version bump. A deprecation decision. All of that requires knowing exactly what is out there. And that is the problem waiting on the other side of the next change. The upgrade problem. Nobody plans for. So here is that change nobody planned for. Picture a dataset control that has done its job well. It is deployed once. It is now sitting inside 40 different forms. It spans a dozen different business units. It works. People rely on it. And then a business requirement shows up. One that cannot be solved without a breaking change. And you required field a different data shape. Something that cannot just slide in as a quiet patch. Here is what that actually means. This is not a change to one app. It is a change to every app in form that references that component. All at once. The moment the update goes live. 40 forms. 40 different teams. 40 sets of users who never asked for a change. That is the blast radius. It is not a metaphor. It is a literal description of how many places a single line of code will touch. This is where manifest versioning earns its keep. But it is from a different angle than before. Earlier versioning was about traceability. Knowing what shipped and when. Here it is about containment. A properly incremented version means the update does not silently overwrite everything. It does not break what every consuming app was depending on. It creates a clear line between the old behavior and the new behavior. Without that discipline, a breaking change does not announce itself. It just shows up. In front of users, they open a form and find something different than what was there yesterday and then the help desk phone start ringing. So what does handling this correctly actually look like? It is not a single push to every environment. That is the instinct when you are under deadline pressure. Get it everywhere at once. Get it done. That is also how 40 forms break simultaneously. The correct pattern is a stage rollout. You move through the managed environment path we already established. Deferst. Then test. Then a limited slicer production. What's what happens at each stage? From the forms that depend on its still behave correctly, then let it reach the full set of apps deliberately in stages. Do not do it all at once out of impatience. This moment matters more than almost anything else. This is the point where governance either proves its value. Or it falls apart completely. All the structure from earlier, the catalog, the environment strategy, the review process, none of it was really being tested until right now. A catalog is easy to maintain when nothing is changing. An environment path is easy to respect when there is no pressure. But an upgrade with a 40 form blast radius is the real test. That is where the structure either holds. Or it gets abandoned because someone decided staging was taking too long. React, fluent UI, and the cost of standing out. Before you even start building that upgrade, a decision happens. It happens the moment someone initializes the component. Standard template. Or react based template. Most teams treat this like a coin flip or a matter of taste. Usually just picking whichever one the last tutorial they watched happened to use. But it's not a coin flip. It's an architectural decision. And it's one worth slowing down for. Here is the plain version of why this matters. When you build a PCF component on a React template, that component doesn't ship its own copy of React to the browser. It taps into the React runtime, the platform is already running. Every model driven app and every canvas app with code components enabled already has React loaded. So the platform is already paying that cost once for everything. A React based PCF control rides on top of that existing runtime instead of packing its own copy into the bundle and shipping it separately to every user who opens the form. A standard template component doesn't do that. It's not wrong and it's not automatically worse. But it's not tapping into anything shared either. It's just its own island of code, self-contained. Which is fine right up until you have a dozen of these islands on the same form. Each one potentially duplicating logic the platform already has sitting right there. Unused. So here is the architectural point underneath the technical detail. Choosing React isn't about which template feels more modern. It's about keeping bundle size down because a component that reuses the platforms existing runtime is lighter than one that reinvents it. And it's about keeping the UI consistent with the rest of the platform because React components built this way use the same underlying rendering approach as everything else on that screen. That's the same discipline we walked through with bundle bloat earlier. Except this time it's not a mistake inside the component. It's a structural choice about whether the component plays well with everything around it or quietly duplicates what's already there. Now the honest trade off pretending this is a free upgrade would be dishonest. React adds a learning curve. Not everyone building PCF components already knows. React, its patterns or its way of thinking about state and rendering. That is not a small gap for a team used to standard templates and vanilla typescript. Which means choosing React isn't purely a technical call. It's a resourcing decision. Does the team have that skill? Or does it need to build it or hire for it? Pretending the learning curve doesn't exist just pushes the cost somewhere less visible usually into a component that took three times longer to build than it should have. But here is why this decision doesn't stay contained to one control. The consistency argument matching the platforms existing rendering approach doesn't stop mattering after the first component ships. It compounds. Every component built the same way adds to a visual and technical language that either holds together across the tenant. Or starts fragmenting the moment different teams make different choices. Which is exactly where the conversation has to go next. Because the same question that applies to React applies just as directly to what these components actually look like once they are rendered. Fluent UI as a governance signal. So here is the part of that visual language decision that most teams treat as an afterthought. It deserves better than that. Using fluent UI isn't a design preference. It's a compliance signal. Whether anyone building the component thinks of it that way or not. Here is what that actually means in practice. A component built with fluent UI looks like it belongs. Same spacing, same type scale, same interaction patterns, the rest of the platform already uses. A user opening a form can't tell where the native controls end and the custom one begins. And that is exactly the point. A component that looks native builds trust automatically without anyone having to argue for it. And the questions are feel that looks like every other field on the form. But a component that looks bolted on. Different fonts, different spacing, a button that behaves nothing like the buttons around it. Invites scrutiny. It may not even deserve on the merits. Users notice the scene before they notice whether the thing actually works well. And once something looks off, it doesn't just get ignored. It gets worked around. People start avoiding the custom control and building their own shadow version of whatever it was supposed to replace. Which puts you right back in the sprawl this entire episode has been trying to close. Now inside Fluent UI itself, there is a decision architecture teams can't dodge. Version 8 versus version 9. Different styling. Different underlying approach. Components build on one don't automatically feel consistent sitting next to components built on the other. This isn't a detail to leave to whoever happens to be building each component that week. It needs a stated position. It needs a documented choice about which version the organization is standardizing on. The same way the catalog documents, which components are approved in the first place. Move it unstated and you end up with some controls that feel like 2019 and others that feel current, sitting on the same tenant, sending mixed signals, nobody intended to send. Here is where this compounds into something bigger than any one component. A 100 components built consistently using the same Fluent version and the same visual language readers platform. They feel like they were designed by one team with one set of standards even if 40 different people built them over three years. A 100 components built inconsistently read as risk. Because any single one is broken, but because the inconsistency itself is the signal. It tells anyone looking. Security compliance, a new architect doing an audit that there is no coordinating structure behind what has been deployed, which is really what this whole argument has been about from the start. Visual consistency isn't about aesthetics, it's about trust. And trust is the actual currency this entire governance model runs on. The trust economy of a governed platform. Let's pull back from Fluent UI for a second. We need to name what we've actually been talking about this whole time. That's the real subject running underneath every part of this episode, whether we use that word or not, but here's the reframe worth sitting with. A governed PCF strategy isn't what slows down low-code adoption. It's what lets leadership say yes to more of it. That sounds backwards if you've spent time in an organization where governance is just the thing standing between makers and getting stuff done. But think about what leadership is actually weighing. Every time someone asks for broader access, more environments, more permission to build. They aren't weighing the idea of low-code itself. They're weighing their last experience with it. If that last experience was clean, a component that shipped through the catalog, moved through dev and test the way it was supposed to, and behaved exactly as documented. Then the next yes becomes easy. Governance isn't a tax on adoption, it's the thing that makes adoption, survivable enough to keep doing it. Because in reality, the opposite is also true. Every ungoverned app that breaks in production doesn't just cause one bad afternoon, it makes the next approval harder to get. Leadership remembers the outage, they remember the emergency call, and they remember explaining to their own boss why a form used by hundreds of people just stopped working with no warning that memory doesn't stay contained to the one app that broke. It attaches itself to the whole category, low-code custom components, anything that sounds like it. The next request for access gets measured against that memory, not against its own merits. Trust doesn't erode evenly. It erodes in spikes, and every ungoverned failure is a spike. This is where that ROI figure from earlier stops being an abstract statistic and becomes the actual mechanism at work. Governance that account for technical debt see roughly 29% higher ROI than those that ignore it. That gap isn't some separate financial curiosity, it's the same conversation. Governed platforms produce that ROI gap specifically because trust compounds. Every clean rollout buys the next one a little more room, every failure spends that room down. And this is exactly why security and compliance teams aren't a separate audience anymore. PCF governance used to be treated as a developer concern, or maybe an architecture concern, but definitely not something compliance needed is seated at the table for it. It's no longer accurate. The audit trail, the environment segmentation, the version discipline, all of that is compliance is story now too. It's not adjacent to the work, it is the work, which raises the obvious question, what does this actually look like when an organization tries to build it for real, not as a theory, but as an actual rollout? A realistic rollout pattern. So what does an actual rollout look like? Stripped of the theory? And laid out as something a platform team could genuinely start on Monday? There's a pattern to it. It's not complicated in concept, even if it's demanding in practice. First. It's not a guess, but an actual pass through the tenant to see what components are already out there. You need to see what's duplicated, and what's quietly holding 40 forms together with zero documentation behind it. Then. Define the catalog. The real one. Versioned and owned. Not just a wiki page. Then, pilot with one high value component, picks something with enough reach to matter. But small enough to get right the first time. Only after that pilot proves the pattern works, does the team scale it out further. But here's the problem. There is attention sitting underneath that sequence. And it's what stalls most of these efforts before they even start. A platform team wants tenant-wide consistency. They want the whole thing. DevTestProDiscipline, one catalog, one visual language everywhere right now. That's the intention. The obstacle is that existing apps brawl doesn't care what the platform team wants. There are already hundreds of canvas apps out there. Built over years, by people who've since moved teams, using patterns nobody documented, you can't consistency your way through that in one pass. The obstacle isn't going away just because the intention is good. So what's actually happening is a shift in strategy. The resolution is less dramatic than most teams expect. They don't rebuild everything. That's not a shortcut. It's the only version of this that's actually achievable. Instead, they govern the highest traffic screens first. The forms and apps that touch the most people. And carry the most risk if something breaks, get the catalog treatment. They get the environment path and the review process. Everything else waits. The catalog grows from there. One governed component at a time. It expands outward from where the stakes are highest. Instead of trying to cover the whole tenant at once and covering none of it well. And here's the timeline reality that leadership needs to hear stated plainly. This is a multi-quarter shift. It's not a sprint. It's not a weekend project. And it's not something that gets wrapped up before the next budget review. Auditing takes time. Building a real catalog takes time. Piling one component properly. Watching it move through dev and test before it touches production takes time. Anyone promising this in six weeks is promising something that skips the exact steps that make governance worth doing. None of this pattern holds if the people funding it don't understand what they're actually paying for. A multi-quarter rollout. Gov. One screen at a time. Sound slow next to a UI refresh that ships in a week. If leadership is expecting the second thing and gets the first. The whole effort loses air before the catalog even reaches double digits. That's where things change. The real next conversation isn't about sequencing anymore. It's about making sure the people signing off. Understand exactly what this spending actually buys. What leadership is really funding. Let's name what leadership actually thinks they're approving when this budget request lands on their desk. Most of the time they hear component library or governance framework. They file it mentally under UI project. A refresh. Something designer Jason nice to have. And easy to delay if the quarter gets tight. That framing is wrong. And it's worth correcting before the request ever gets submitted. This isn't a UI project. It's platform infrastructure spend. It belongs in the same category as your environment strategy. The same category as identity management. The same category as anything else that has to hold firm before you build a single thing on top of it. The technical debt research makes the case for this reframe in the planist terms possible. Unfunded governance doesn't just disappear. It moves. It shows up later as unplanned remediation cost. This is the exact expense nobody put a line item against because nobody wanted to admit it was coming. That's the mechanism underneath the ROI numbers we've already covered. The gap isn't between spending on governance and not spending at all. It's between spending on it now deliberately on a timeline you control. Spending on it later urgently on a timeline and outage controls for you. Then there's the alternative cost that almost never makes it into the original budget conversation. It stays hidden because it's scattered across categories that don't look connected on paper. Firefighting broken apps. The emergency calls, the after hours fixes, the apology emails to whoever's form just went down. Security review backlogs happen because nobody cataloged what's actually running so every audit starts from zero instead of from a known inventory. Shadow 80 workarounds appear because the business units got tired of waiting and built their own version of whatever the platform team never got around to governing. None of that shows up as a single number leadership can point to. It shows up as friction. It's spread across a dozen teams and each one absorbs a piece of a cost that was never budgeted anywhere. So here's the reframe one last time. Architecture over UI isn't a design preference. It's a funding decision. Every dollar spent on the catalog, the environment path and the review process is a dollar spent avoiding the much larger, much less predictable bill that shows up when none of that exists. Up isn't choosing between spending and not spending. They're choosing between a number they control and a number they don't, which leaves one honest question. What do you actually do with this on Monday morning? The blueprint, not the skin. Here's the transformation stated as plainly as it deserves. PCF stops being a UI trick. The moment you start treating it as the enforcement layer for the whole platform. It's the thing standing between the tenant that scales and one that quietly comes apart under its own apps brawl. So here's the direct challenge. Don't wait for a framework meeting. This week audit one high traffic app not to see how it looks to see who owns its components. Ask who built them, ask what they're bound to, ask whether anyone could tell you today if that control broke tomorrow. If this reframed how you think about power platform governance, leave a review. It helps more people find this. And if you want to help shape where this goes next. Follow me, Mirko Peters on LinkedIn. The tenants that scale are the ones that stopped treating components as decoration.