Forem: Riccardo Gregori

PCF's default Fluent UI version is broken... and how to fix it

Riccardo Gregori — Mon, 25 May 2026 17:56:15 +0000

If you build PCF (Power Apps Component Framework) controls for Dynamics 365 / Power Platform, there's a very good chance you've already hit this wall — or you will, the next time you spin up a new control. It's one of those small, infuriating papercuts that has nothing to do with your code and everything to do with the tooling assuming things about your target environment that simply aren't true.

Let me walk you through it.

⚙️ The Setup

You do what the docs tell you to do. You open a terminal, you run:

pac pcf init --namespace MyNamespace --name MyControl --template field

(or --template dataset, it doesn't matter — the bug is template-agnostic).

The CLI happily scaffolds the project for you: index.ts, ControlManifest.Input.xml, package.json, the tsconfig, the lot. You write your control, you test it locally with npm start, everything looks great. You're feeling productive.

Now look at what the scaffolding generated for the Fluent UI dependency.

In ControlManifest.Input.xml:

<platform-library name="Fluent" version="9.68.0" />

In package.json:

"@fluentui/react-components": "9.68.0",

Both files agree. The CLI is internally consistent. Surely Microsoft's own tool wouldn't hand you a default that doesn't work… right?

❌ The Crash

You package the control into a solution (managed or unmanaged, doesn't matter), you push it to your target environment, and the import blows up:

Error: Import Solution Failed: CustomControl with name  failed to import with error:
CustomControls with Name <YourControlName> Import Solution Failed with following error:
platform library fluent_9_68_0 with version 9.68.0 is not supported by the platform.

😠🤬 The version the CLI just generated for you, two minutes ago, isn't the version actually supported by the platform.

🔨 The Fix

You need to manually downgrade Fluent in both places to a version the platform actually accepts. At the time of writing, the version that works for me is 9.46.2.

So ControlManifest.Input.xml becomes:

<platform-library name="Fluent" version="9.46.2" />

And package.json becomes:

"@fluentui/react-components": "9.46.2",

Then npm install, rebuild, repackage, reimport.

🧐 Takeaways

Don't trust the scaffolded Fluent version. As soon as pac pcf init finishes, check ControlManifest.Input.xml and package.json, and swap the version to one your environment actually supports.
Keep both files in sync. They have to match, or you'll get a different — equally cryptic — error at build or runtime.
9.46.2 is a known-good value for me right now. Yours may differ depending on what your target environment has rolled out; the safest move is to check what other working controls in your tenant declare and copy that.
If you maintain a starter template / yeoman generator / project scaffold at your company, hard-code the Fluent version there and stop relying on the CLI's default. You'll save every junior dev on your team a half-day of debugging.

It's a small thing. But it's a small thing that has tripped me up on every single PCF I have ever created, and judging by the volume of forum posts on the subject, I'm very much not alone.

Fingers crossed that Microsoft will fix this soon, so that the next dev running pac pcf init gets a project that just works.

Power Pages SPA, local authentication, and the "Private" flag that blocks local development

Riccardo Gregori — Sun, 24 May 2026 07:31:58 +0000

TL;DR: if you're developing a Power Pages SPA locally with local authentication (not Entra ID) and the login redirects to Microsoft with a redirect_uri pointing to the production URL, the issue isn't in your application configuration. It's the portal's "Private" flag in the admin center. Switching it to "Public" unblocks the flow.

📖 Background: Power Pages SPA

For those who haven't come across it yet, Power Pages Code Sites is the "code-first" mode of Power Pages portals: it lets you build the portal as a Single Page Application (React, Vue, or other frameworks), instead of managing its content through Liquid and the Dataverse admin interface.

One of the main advantages of this approach is the local developer experience: you spin up the dev server (typically Vite, on localhost:5173), and the portal behaves as it would in production, talking to the remote backend of your development environment. This way, you don't need to push every change to verify it works.

At least in theory.

🔗 The constraint: local authentication

In its official documentation, Microsoft advises against using local authentication on Power Pages portals, recommending external providers such as Entra ID or other configurable identity providers.

In my case, however, client constraints required local authentication: no Entra ID for end users, no social login, just locally managed usernames and passwords.

This is where the first hurdle shows up: all the documentation and examples available online for Power Pages SPA authentication assume Entra ID. Searching for "Power Pages Code Sites authentication" returns guides on configuring Entra app registrations, handling JWT tokens, and silent token renewal. For local auth, you get a few lines confirming that it's supported, with no further detail.

The missing documentation can be reconstructed by reading the output generated by the published portal and analyzing its behavior. It's extra work, but it's doable.

🧱 The authentication stack

To give you a concrete reference, here's — in simplified form — the React context that handles authentication on the client side. The logic is fairly straightforward: a reducer for the auth state, a fetch helper that first tries the user object injected by Power Pages into window and then falls back to a REST endpoint, and login/logout methods that redirect to the portal's native endpoints.

// AuthContext.tsx (simplified)

interface PowerPagesUser {
  userName?: string;
  firstName?: string;
  lastName?: string;
  email?: string;
  contactId?: string;
}

declare global {
  interface Window {
    Microsoft?: {
      Dynamic365?: {
        Portal?: {
          User?: PowerPagesUser;
        };
      };
    };
  }
}

async function fetchUser(): Promise<AuthUser | null> {
  // 1. Window object (production, page-load check)
  const ppUser = window.Microsoft?.Dynamic365?.Portal?.User;
  if (ppUser?.userName) {
    return {
      id: ppUser.contactId ?? '',
      email: ppUser.email ?? ppUser.userName,
      fullName: `${ppUser.firstName ?? ''} ${ppUser.lastName ?? ''}`.trim(),
      contactId: ppUser.contactId ?? '',
    };
  }

  // 2. Fetch fallback (post-login session check / local dev)
  const res = await fetch('/_services/auth/user');
  if (!res.ok) return null;

  // ... parse the JSON response or the HTML with embedded data ...
}

And the login/logout methods:

const login = useCallback(async () => {
  window.location.href = '/Account/SignIn';
}, []);

const logout = useCallback(async () => {
  window.location.href = '/Account/Login/LogOff?returnUrl=%2F';
}, []);

Everything is delegated to the endpoints Power Pages exposes natively: /Account/SignIn is the portal's login page, /Account/Login/LogOff is the logout endpoint. On the SPA side, after login the user is returned to the site, the page reloads, and the fetch helper retrieves the user from the window object.

In production, all of this works correctly. On the portal's public URL, the login button opens the native page, credentials are validated, and the session is established as expected.

🐛 The problem: the wrong `redirect_uri`

Locally, things were different.

The scenario was as follows:

I was working on a development portal configured as "Private" in the Power Pages admin center. Private means the portal is only visible to Entra ID users explicitly assigned as "portal users" in the admin center: a sensible choice during development, to prevent unintended access to a work-in-progress site.
On the same portal, Entra ID authentication for end users was disabled: portal users authenticate via local auth.
Running npm run dev, the portal starts on localhost:5173. When you click the login button, however, the local portal login page doesn't open — instead, the browser is redirected to login.microsoftonline.com.

The behavior, in itself, makes sense: the portal is "Private", so before any page can be reached — including the local login page — Power Pages requires the developer to authenticate via Entra, to verify that they are authorized to view the portal.

The problem lies in the redirect_uri of the request to Microsoft:

https://login.microsoftonline.com/.../oauth2/v2.0/authorize
  ?client_id=...
  &redirect_uri=https%3A%2F%2Fmy-dev-portal.powerappsportals.com%2F...
  &response_type=code
  &scope=...

That redirect_uri points to the portal's public URL, not to http://localhost:5173. As a result, once the Entra authentication flow completes, Microsoft redirects the browser to the portal's public URL — the one configured in the underlying app registration — and the local flow breaks: the dev server is on localhost, the local code is no longer running, and the session built locally is lost.

The practical outcome is that the login cannot be completed locally, and therefore no part of the application that requires authentication can be tested locally without first deploying to the published portal 😵😟.

🔍 The search for a solution

Looking for a solution online, I didn't find much useful material.

Googling for combinations like "Power Pages Code Sites local development authentication", "Power Pages SPA private site redirect_uri localhost", or "Power Pages Vite dev server login loop" returns always the official documentation on configuring Entra authentication for portal end users, which is a different scenario from the gate for private portals.

Asking an AI assistant didn't help either, which is worth mentioning.

These days, when the documentation falls short, the natural next step is to turn to a coding assistant — and for most problems it works. Not here: Power Pages Code Sites is recent enough, and this particular combination of settings is niche enough, that there's barely any signal in the training data. The answers I got back were either generic guidance on Entra app registrations (the same material I'd already found in the docs), or plausible-sounding but ultimately wrong suggestions — the kind of confident answer that wastes more time than it saves, because you end up verifying it before discarding it. When a technology is both new and poorly documented, AI assistants reflect that gap rather than filling it.

I tried several approaches manually: checking whether localhost:5173 could be added as a valid redirect URI in the app registration used by Power Pages for the private-portal gate (it cannot, because that app registration is managed internally and isn't exposed to the tenant administrator); tracing where that redirect_uri was generated by inspecting the client-side code; setting session cookies manually; calling the auth endpoints with custom headers.

None of these led anywhere. The redirect_uri of the private-portal gate is effectively bound to the portal's production URL, and cannot be overridden from the client.

✅ The solution

After spending a fair amount of time exploring alternatives, the solution turned out to be a single change in the Power Pages admin center:

Power Pages admin center → Site Details → switch the flag from "Private" to "Public".

That's all. By disabling the Entra gate at the portal level:

The local dev server can reach the portal's endpoints without first having to clear the Entra login.
/Account/SignIn opens the portal's local auth page directly.
The login completes, the session is established, the fetch helper retrieves the user, and local development is operational again.

The reason this works is that the "Private/Public" flag has no role in end-user authentication, which remains handled by the configured providers (in my case, local auth). "Private/Public" controls the outer gate that Power Pages places in front of the portal and that requires Entra authentication only to access the portal itself. Disabling it removes the second authentication layer that, locally, was running into the wrong redirect_uri.

📝 A note on the documentation

It's worth making one observation about the documentation. The "Private" flag is described as a feature intended for the development phase, useful for protecting a work-in-progress portal from unintended access. In practice, however, it is incompatible with one of the main development patterns of Code Sites mode, namely working locally with the dev server.

This incompatibility isn't documented: there is no warning, footnote, or FAQ flagging it. The problem is also specific:

With Entra ID also configured for end users, the "Private" flag causes no issues locally, because the gate flow and the application authentication flow converge and the redirect is handled consistently.
It is only in the combination "Private" + "local auth for end users" that the flow breaks. And this is precisely the combination least covered by the official documentation.

⚙️ Operational notes

A few practical notes for anyone in the same situation:

1. First and above a all, avoid local auth whenever possible

2. Document the constraint in the repository. It's worth adding a LOCAL_DEV.md file or a README section that clearly states: "To develop locally, the Power Pages portal must be set to 'Public' in the admin center. Switching it back to 'Private' prevents login from completing locally." It's information that will save time for future developers on the project.

🧐 Conclusions

The "local auth + local development" scenario on Power Pages Code Sites is one of the least documented, but it's realistic in many enterprise contexts — particularly when existing identity management systems are already in place and can't be replaced by Entra ID for end users. I hope this article is useful to anyone walking the same path, especially to those searching for an answer online after a few unproductive hours of troubleshooting.

Vibe coded Power Pages SPA: unfiltered

Riccardo Gregori — Mon, 11 May 2026 08:02:08 +0000

Today I tried something that feels deeply unnatural to me.

Not just uncomfortable—almost wrong.

Partly to challenge my own mental limits and break through some of my built-in biases. Partly to answer a question I’d been avoiding for a while: how far can I really go if I stop controlling everything and just… trust the technology?

I don't like blog posts describing vibe coding as "type something, do something else, and everything magically works". So I wanted to give it a try by myself, reporting everything I face on my journey. The goods, and the bads.

So I set myself a rule: no shortcuts, no safety nets.

I tried to build a Power Pages SPA portal from scratch—without using PACX, and without any of the templates or tools I’ve spent years building to make my life easier.

Just an empty folder in VS Code.

And two simple plugins provided by Microsoft.

💡 Let's start with the idea

I’ve never been particularly fond of our corporate welfare portal, so I decided to ask my trusted friend, M365 Copilot:

Help me draft the requirements for a corporate welfare website.
Be synthetic, it's for a demo. Don't design approval workflow or too fancy features. Draft everything in markdown.

And the result is:

# 📌 Requirements – Corporate Welfare Portal (Demo)

## 1. Objective

The portal aims to provide a simple solution that allows employees to:

- View their available welfare budget  
- Access a catalog of available services  
- Request benefits (vouchers or reimbursements)  
- Monitor the status of their requests  

## 2. Actors

- **Employee**
- **HR / Administration**

## 3. Functional Requirements

### 3.1 User Access and Profile

- Access via corporate login (SSO)  
- User profile view including:
  - name and role  
  - available welfare budget  

### 3.2 Budget Management

- Display of:
  - available budget  
  - used budget  
- HR capability to assign and update budget  

### 3.3 Welfare Catalog

- Display available services:
  - organized by categories (e.g., health, education, leisure)  
- Search and filtering capabilities  
- Service detail view including:
  - description  
  - eligible amount  
  - usage conditions  

### 3.4 Benefit Request

#### Voucher

- Service selection  
- Voucher generation  
- Automatic budget deduction  

#### Reimbursement

- Submission of reimbursement request  
- Upload of supporting documents (e.g., receipts)  
- Request status tracking  

### 3.5 Operations History

- List of user requests including:
  - date  
  - type  
  - amount  
  - status  
- Detailed view of individual requests  

### 3.6 HR Back Office

- User management:
  - budget assignment  
- Catalog management:
  - create and update services  
- View user requests  

## 4. Non-Functional Requirements

### 4.1 Security

- Authenticated access (SSO)  
- Personal data protection (GDPR compliance)  

### 4.2 Usability

- Simple and intuitive user interface  
- Accessible from desktop and mobile devices  

### 4.3 Performance

- Fast response time for standard operations (within a few seconds)  

### 4.4 Traceability

- Logging of user operations  
- History of submitted requests  

## 5. Open Points (for Demo / Future Evolution)

- Integration with HR systems  
- Automatic handling of fiscal constraints  
- Catalog extension (new services)  
- Personalization based on employee segments  

## ✅ Demo Implementation Suggestion

- **Frontend:** Power Pages  
- **Backend:** Dataverse  
  - Tables: Users, Budgets, Services, Requests  
- **Automation (optional):** Power Automate for notifications

More than enough for a simple demo.

To start, I've:

created a local folder called neronotte01-site, that will be the root of our workspace.
opened the folder in VSCode
copied the above text and pasted it in a requirements.md file under the docs folder of my repo.

Now my repo looks like this:

- 📂 neronotte01-site
  - 📂 docs
    - 📄 requirements.md

Now let's start by asking Copilot

Starting from the attached requirement document, design
and implement a power page portal with a modern and
effective UI. Put the source code in the /portal subfolder

Note: I prefer using Claude Sonnet 4.6 for this kind of tasks, so I started with that model.

Copilot starts by building a plan:

And then goes... coding everything following the plan. In this first draft it designs the site UI and wires up mock data, but that's good as a start.

After a couple of minutes the build is completed:

And this is the working result:

Pretty good result by now, considering we started from a simple spec document.

Now let's try to build the backend and manage the authenticated flow.

💻 Let's build the backend

Let's move forward by asking copilot to create the tables:

After a bit of reasoning, Copilot starts asking a couple of questions:

What will be the publisher prefix: nn
How shoud he call the solution that will contain the tables: portal

Now we fought a bit around Python structure. I'm not (and I wont be) a Python developer. I have PIP installed in my machine, but just for the sake to run some script... so Copilot tried to initialize a virtual environment to launch the commands into.

In this step there was a lot of "try and error".

But let's trust the process... for now.
After a few more tries, we got stuck on an authentication issue towards Dataverse.

After the analysis, Copilot came up with another solution:

The device code flow is blocked by Conditional Access policies. 
Since `az` CLI is already authenticated, let me use it 
to get a token directly for the Dataverse API instead.

And... it worked!

`az` CLI can get a Dataverse token. 
Now I'll write a comprehensive Python script that uses it 
to create the publisher, solution, and all 3 tables via 
the Dataverse Web API.

Copilot did 3 things:

added a .env file at the root of my workspace

# .env
DATAVERSE_URL=https://neronotte01.crm4.dynamics.com/
TENANT_ID=31c42b90-d584-4ff8-b5b9-1c65de456516
MCP_CLIENT_ID=***REDACTED***
SOLUTION_NAME=Portal
PUBLISHER_PREFIX=nn
PAC_AUTH_PROFILE=neronotte01
CLIENT_ID=***REDACTED***

created a folder called scripts in my repo
added 2 files in that folder: auth.py and create_tables.py. The second is the one containing the actual datamodel setup:

Then it asked to run the script:

Unfortunately the run failed ❌. Authentication issue, again.

Long story short, I had to provide a client secret to make it work. It updated the .env file adding CLIENT_SECRET= at the bottom

# .env
DATAVERSE_URL=https://neronotte01.crm4.dynamics.com/
TENANT_ID=31c42b90-d584-4ff8-b5b9-1c65de456516
MCP_CLIENT_ID=***REDACTED***
SOLUTION_NAME=Portal
PUBLISHER_PREFIX=nn
PAC_AUTH_PROFILE=neronotte01
CLIENT_ID=***REDACTED***
CLIENT_SECRET=***REDACTED***

And it updated also the script with a few changes to leverage that client secret.

A few try-and-error again, and we got the result:

🤔 My personal opinion on this step

With PACX it would have been WAAAAAAAY more straightforward. I do the same step almost daily (asking GH Copilot: "start from a requirement document and draft the datamodel, then build the PACX script to create it"), and it goes as a charme. PACX wins drastically on this.

🔗 Let's wire things up

Third prompt to Copilot:

Now replace mock data with actual calls to 
the Dataverse tables you just created

It started by drafting a 7 step plan:

Install @azure/msal-browser
Create MSAL config + auth context
Create Dataverse service layer
Wrap main.tsx with auth
Update Navbar to use real user
Update all 5 pages to use Dataverse
Build and verify

It runs for 5-6 minutes, and then...

It asks me to configure the app registration properly on Azure. Once done, I launch the portal and it looks like this:

But... unfortunately the login is not working. If I click on the "Sign in with Microsoft" button, it opens a popup where I can peek the user (riccardo@neronotte1.onmicrosoft.com). Then it moves to the next screen, reopening the login page into the popup. And there I'm stuck.

I say the same stuff to the copilot and try, collaboratively, to fix it.

After a while, it cames with a solution:

The problem is that after authentication, Microsoft redirects 
the popup back to window.location.origin — which loads the 
full React app inside the popup, showing the login screen again.

The fix is a dedicated blank redirect page for the popup, 
which is the MSAL-recommended pattern for SPA popup flows.

...

Now you need to add http://localhost:5173/blank.html as a 
redirect URI in the Azure App Registration. Go to:

Azure Portal → App registrations → 6beaf75f-4793-4b3f-b364-14b9647556f2 
→ Authentication → Single-page application 
→ Add URI → http://localhost:5173/blank.html

OK. I do it, try again and...

I'm still stuck. Let's go to copilot again:

Now it goes to blank.html, but remains opened (see attached screenshot).

But this time i decided to change model, from Claude Sonnet 4.6 to GPT 5.4 (sometimes it is more effective).

It started working again for a while and...

boom solution found. It was a problem on how the App Registration was configured. Now the portal opens properly:

But, of course without data.

🤔 My personal opinion on this step

On Power Pages SPA you have to rebuild the auth method from scratch every time. To avoid an useless token burning, do it once until it works properly, then extract the AuthContext.tsx that works, and reuse it across all your sites.

I did it, creating my own Power Page template that I reuse every time.

✍🏻 Create sample data

I don't want to do it manually, so let's leverage Dataverse MCP server for this purpose.

First of all we need to enable it.

Access https://admin.powerplatform.microsoft.com/
Go to Manage > Environments
Select the environment that contains the portal
Click on Settings > Product > Features
Scroll until you find Dataverse Model Context Protocol

in the Step 2: Add MCP clients to allow list select Advanced Settings
in the Allowed MCP Clients list, ensure Microsoft GitHub Copilot App is enabled:

Now let's setup the MCP Server in VSCode

On VSCode, click CTRL+SHIFT+P to open the command palette
Select MCP: Add Server...
Select HTTP as streaming
Add your MCP url, https://{environment}.crm4.dynamics.com/api/mcp
Select Workspace as the place where to save the MCP config (it will create a local .vscode/mcp.json file with the MCP configuration)
Insert Dataverse as the MCP name

The mcp.json file will be something like:

{
  "servers": {
    "dataverse": {
      "url": "https://{environment}.crm4.dynamics.com/api/mcp",
      "type": "http"
    }
  },
  "inputs": []
}

Now we're ready. Let's ask copilot:

Now create sample data into the dataverse tables 
you've created, to show something into the app.

It iterates for a couple of minutes and then...

I refreshed the browser, and the data appears.

And if I try to create a new request... it works! Request is created and saved in dataverse!

📦 One more to go: deploy

As of now we've worked locally. Let's deploy the site into the dev environment. Let's type in the Copilot chat:

Now publish the site to dataverse

And it started thinking...

It tried to upload the site, but got stuck on the fact that the JS attachments are blocked, as described here.

Fortunately it stopped here, because in the /dist subfolder I can clearly see there's the issue I described in my previous article, so I decided now to manually update the vite.config.ts before moving forward.

Once I've updated my vite.config.ts in the following way:

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

export default defineConfig({
  plugins: [react()],
  build: {
    outDir: "dist",
    rollupOptions: {
      output: {
        entryFileNames: `assets/[name].js`,
        chunkFileNames: `assets/[name].js`,
        assetFileNames: `assets/[name].[ext]`,
        manualChunks: {
          router: ["react-router-dom"],
          msal: ["@azure/msal-browser"],
        },
      },
    },
  },
});

Note: it's using @azure/msal-browser, even if as stated here you should use ADAL.js... but it's working, for now, so let's leave it as it is.

I typed Yes, remove js from blockedattachments and retry in the GitHub Copilot chat, and it run the following:

$blocked = 'ade;adp;app;asa;ashx;asmx;asp;bas;bat;cdx;cer;chm;class;cmd;com;config;cpl;crt;csh;dll;exe;fxp;hlp;hta;htr;htw;ida;idc;idq;inf;ins;isp;its;jar;jse;ksh;lnk;mad;maf;mag;mam;maq;mar;mas;mat;mau;mav;maw;mda;mdb;mde;mdt;mdw;mdz;msc;msh;msh1;msh1xml;msh2;msh2xml;mshxml;msi;msp;mst;ops;pcd;pif;prf;prg;printer;pst;reg;rem;scf;scr;sct;shb;shs;shtm;shtml;soap;stm;tmp;url;vb;vbe;vbs;vsmacros;vss;vst;vsw;ws;wsc;wsf;wsh'; 

pac env update-settings --name blockedattachments --value "$blocked"

Of course it worked. Once done, it run again pac pages upload-code-site to upload the site.

Next step is (as per GH Copilot suggestion):

Activate/provision the site if it is not already live
Test the deployed site end-to-end in the browser
Clear/restart the site cache so the latest changes appear immediately

In fact, if I go to make.powerpages.microsoft.com, I can clearly see the site uploaded and disabled, ready to be reactivated.

Note: since this was the first site created on this environment, once I got into https://make.powerpages.microsoft.com/ I had to create a new, empty, website to move forward, otherwise the portal didn't get me to the page where I could barely reactivate the old one. I think it's a sort of bug... hope Microsoft fixes this soon.

The reactivation took a while (almost 30 minutes), but... once done...

Wrong portal?!

Let me ask Copilot:

The published portal is showing something completely different, 
see attached screenshot.

At first, Copilot hypothesis was a site mismatch between the one I had to create manually, and the one generated by it... but of course that wasn't the problem. First miss.

Then it tried with other stuff... let me skip the details. Unconclusive.

Then I spotted something in the admin center:

It has created the site with Standard data model, while Power Pages SPA requires the Enhanced data model.

I told this to it explicitly:

The problem is the site you deployed is with "Standard" data model, 
while power page SPA works with the Enhanced data model. 
I think you have to re-create the site completely.

It started iterating for several minutes, but no meaningful solution came out. I even tried to change model back to Sonnet 4.6... useless.

After more than 1h of try-and-error, I tried the old way:

Create a new empty website. It gets created with Enhanced datamodel by default
changed the value of the sitename node of my local powerpages.config.json to the name of the newly created site
opened the local /portal/.powerpages-site/website.yml and changed the id node to the GUID of the newly created website
Manually push the code to this new site via pac pages upload-code-site -rp .
Purged the cache via admin center.

Et voilà... site up and running!

...not so fast... at login:

We need to fix this other app registration:

Go to https://portal.azure.com/
Select App Registrations > All applications
Select the App Registration mentioned in the screenshot by ID
Select Authentication
Click Edit button near the Redirect URI configuration for Single-page application
Add the Url of your website and click configure (don't forget to add also /blank.html)

Now let's try again.

In the admin center, refresh the portal cache
Press F5 in the browser and re-execute the login process

And that's it, we're in!

☺️ Conclusions

In the end, this experiment turned out to be far more than just a technical exercise.

Power Pages SPA prove to be incredibly powerful—much more than they might initially appear. When you strip everything down to the bare essentials, the core platform already provides everything you need to build a fully functional solution.

And that’s where the real surprise lies: the tools provided by Microsoft are a true game changer. They cover the entire lifecycle, from development to deployment, in a way that feels cohesive and increasingly mature. You can genuinely go from zero to a working application without relying on any external scaffolding.

That said, it’s not a smooth ride.

There are moments where things don’t click. Where the tooling feels a bit rough around the edges. Where you need to push, tweak, retry—and sometimes just hammer it until it works. And that’s exactly where experience makes the difference. Knowing how the platform behaves, understanding its quirks, and having the intuition to work around them becomes your real advantage.

And this is also where external tools (like PACX) still shine.

Even if the out-of-the-box Microsoft tooling gets you surprisingly far, there are still phases that feel “tricky” or not fully streamlined. External tools don’t replace the platform—they augment it. They smooth out the friction, reduce the cognitive load, and accelerate the parts that would otherwise slow you down. And, most important, the knowledge of who's between the chair and the keyboard still makes the difference.

But the biggest takeaway is probably this:

This way of building changes how you think.

It shifts the balance between control and trust. Between handcrafted tooling and platform-native capabilities. Between “how I’ve always done it” and “what’s now possible.”

And honestly—I didn’t expect to enjoy it this much.

Because once you let go of the need to control every detail, and start embracing what the platform already offers, you realize something subtle but powerful:

You’re not just building differently.
You’re working differently. Focusing on what really matters, and leaving the details behind.

ALM on Power Platform: ADO + GitHub, the best of both worlds

Riccardo Gregori — Mon, 04 May 2026 08:50:02 +0000

TL;DR

You can integrate Azure DevOps with GitHub to get the best of both worlds in Power Platform development.

ADO stays as the backbone: work items, sprint planning, test plans, and deploy pipelines all remain on Azure DevOps.
Code moves to GitHub: Power App Code Apps or Power Pages SPA live in GitHub repos, unlocking native GitHub Copilot integration and the Copilot Cloud Agent.
The two platforms are linked: commits reference ADO work items via AB#{id}, creating a bidirectional traceability layer.
The Copilot Cloud Agent works autonomously: assign it a task, it opens a PR; assign it to a PR, it reviews and fixes issues — all guided by your repo's own instructions.

Managing ALM on Power Platform has never been straightforward. Anyone who works seriously with CRM and business applications knows it: an application's lifecycle doesn't end when the code is written. Requirements, sprints, pipelines, tests, reviews — everything needs to fit together coherently. And for years, my answer to that problem has been Azure DevOps.

🏗️ The starting point: Azure DevOps as the backbone

Azure DevOps has always given me what I needed: Work Items for tracking requirements, Git repositories, CI/CD pipelines, integrated test plans. A complete ecosystem built for teams that want full control over the application lifecycle — from user stories all the way to production deployment.

For Power Platform applications ADO remains a rock-solid choice, whether you're building canvas apps, model-driven apps, or Power Pages portals. Solution pipelines, ALM tooling like Power Platform Build Tools, and native environment integration make the workflow reproducible and governable.

All good.

Then came the Power App Code Apps and Power Pages SPA.

🎮 New App types are changing the rules of the game

Power App Code Apps and Power Pages SPAs represent a paradigm shift: you're no longer working with a low-code designer, you're writing real code — TypeScript, React, custom components. And when you write real code, AI in the development cycle stops being a luxury and becomes a genuine accelerator.

They benefit enormously from AI in their development cycle: code completion, automated review, test generation. This changes the weight of your platform choice significantly.

By company policy, our trusted assistant is GitHub Copilot. And here's where the first point of friction emerges: GitHub Copilot lives on GitHub, not on ADO.

💎 GitHub is more than just a repository

In recent months, with the introduction of the GitHub Copilot Cloud Agent, the platform has taken a significant leap forward. GitHub is no longer a mere Git repo storage: it's an autonomous agent platform, that is able to run agents in the cloud, in the background, like real collaborators.

However, GitHub doesn't match ADO's completeness for the rest of the lifecycle: requirements management, sprint planning, structured test plans — what an enterprise team needs to govern a complex project remains ADO's strong suit.

The question I asked myself was: can I get the best of both?

🔗 The hybrid setup: ADO + GitHub integrated

The answer is yes — and the setup is less complicated than it might sound. Azure DevOps and GitHub integrate natively. Once the connection between the two environments is configured, the two systems start talking to each other bidirectionally.

Code lives on GitHub. Work items, requirements, sprint planning, test plans — everything stays on ADO. Deployment pipelines to Power Platform keep running on ADO Pipelines, with the connectors you already know.

↔️ The bidirectional link in commits

One of the things I cared most about was not losing the connection between code and work items. In pure ADO, this works naturally: a commit can reference a work item and build a traceable link. I wanted the same result in the hybrid setup.

And I have it. The syntax to use in commit messages (or PR comments) is straightforward:

In GitHub commits, use the AB#{WORKITEMID} syntax to automatically link the commit to the corresponding work item on Azure Boards. The link appears on both sides, bidirectionally.

Writing fix: error handling on component init AB#1234 in the commit message is enough to create a traceable link between the code change and the ADO task. The integration automatically populates the "Development" section with a reference to the commit or PR.

Anyone who works with ADO knows how important this kind of traceability is during audits, release planning, or simply when trying to understand "why was this code written this way."

🤖 The Copilot Cloud Agent: a collaborator that works while you sleep

This is the part that genuinely changed how I work. The GitHub Copilot Cloud Agent can be assigned directly to a bug or a task — and from that point, it starts working on it autonomously, opening a Pull Request and building the solution in the background.

The quality of the output depends heavily on how you write the task. A well-structured issue — with clear context, acceptance criteria, and references to the existing codebase — produces a significantly better PR than a vague, one-line title. The investment you make when writing the task pays off when the agent delivers the work done.

But the most compelling part is the automated Pull Request review. The Copilot Cloud Agent:

analyzes every PR opened by developers,
anticipates problems,
flags questionable patterns,
and can be actively engaged to fix them — all inside the PR, in comments, in a collaborative way.

🎯 Contextual review, not generic feedback

There's one aspect that sets this configuration apart from a generic "AI that does code review": the Copilot Cloud Agent works with the repository's context. This means its reviews aren't generic — they're grounded in the guidelines, architectural patterns, and conventions the team has defined in the repository itself.

Through instruction files, skills, and rules configurable at the repository level (.github/copilot-instructions.md and custom instructions), you can teach the agent how your Code App is structured, which patterns to follow, which anti-patterns to avoid, and which naming conventions to enforce.

The .github/copilot-instructions.md file is your control point: here you define architectural guidelines, team conventions, and patterns to follow. The agent uses them as a reference for every review and every task you assign to it.

The result is a review that speaks your project's language — not a generic checklist that anyone could copy from a blog post (including this one). If the team has decided that components follow a certain error-handling pattern, the agent knows it — and verifies it.

Final thoughts

The ADO + GitHub setup isn't a compromise: it's a deliberate choice that leverages the strengths of each platform in the domain where it excels. ADO for governance, planning, and the full lifecycle. GitHub for development, AI, and the Copilot Agent's capabilities.

For teams working on Power App Code Apps — and increasingly on Power Pages SPAs too — this configuration reduces the cost of review, improves the quality of the code produced, and maintains the traceability that an enterprise project demands.

The Copilot Cloud Agent doesn't replace the developer: it anticipates problems, handles the more mechanical tasks, and frees up developers' time for the decisions that matter. And that's exactly what you'd ask of a good collaborator.

One frontier I'm actively looking forward to exploring: bringing the same degree of automation to model-driven apps. Today, the code-first nature of Code Apps is what makes the Copilot Agent so effective — but with tools like PACX, App Maker MCP Server, Dataverse MCP Server, Power Platform Skills for Generative Pages, and so on, the prospect of applying a similar AI-driven workflow to model-driven development is becoming increasingly concrete. Watch this space.

Power Pages SPA Learning By Doing - Keep it clean

Riccardo Gregori — Sun, 22 Mar 2026 15:09:23 +0000

Lately, I’ve been working a lot with Power Pages Single Page Applications (SPA).
I find this approach far more effective than the previous one, and its potential, combined with GitHub Copilot’s ability to generate React code, makes portal development faster, more efficient, and honestly even fun 😎.

Power Pages SPA reached General Availability at the beginning of February, almost two months ago, but even today the official documentation is still not fully exhaustive. Many things can only be discovered by hands-on experimentation with the platform.

This article — or rather, this series of articles — is born with the goal of sharing the pain points and hidden gems I’ve encountered during my personal journey exploring this new technology.

So… what are we waiting for?

Let’s get started! 🚀

🤔 The issue - Stale files generated by chunking strategy

If you build a Power Pages SPA using React+Vite, as in this tutorial, every time you build your portal via:

npm run build

Build process automatically splits your site source code in a set of chunked files

The random-looking hashes in chunk names change because Vite uses content hashes by default. This means that when you change the content of your site, each chunk content may change, thus the chunk name changes too.

Those chunks become Web Files records in dataverse, that are created or updated when you type:

pac pages upload-code-site --rootPath .

Exactly... that command, by itself, adds or updates Web Files, but does not remove old, now unused, files.

On the medium-long run, this is a real issue, because your site definition will be crowded by tens or thousands of useless Web Files, that you will deploy between environments.

💡 How to fix it?

📌 Step A. Apply deterministic names on chunks

To avoid generate random-looking hashed names, you can customize how Vite produces the output files, with different possible strategies:

Important notice: these strategies are tested with Vite 7.3.1. Vite 8 (released March 2026) may require a different approach.

1. Disable hashing entirely (simplest)

In vite.config.ts, override the rollupOptions.output naming:

export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        // Static names — no hashes at all
        entryFileNames: `assets/[name].js`,
        chunkFileNames: `assets/[name].js`,
        assetFileNames: `assets/[name].[ext]`,
      },
    },
  },
});

This gives you fully predictable names like index.js, vendor.js, etc. The downside is no cache-busting, but for Power Pages/ALM this is often exactly what you want.

2. Use a fixed/stable hash (content-based, but stable)

If you want hashes but want them to only change when the content actually changes (which is actually Vite's intent, but chunk splitting can cause cascading renames):

export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        entryFileNames: `assets/[name].[hash].js`,
        chunkFileNames: `assets/[name].[hash].js`,
        assetFileNames: `assets/[name].[hash].[ext]`,
      },
    },
  },
});

The issue here is usually not the hash algorithm but chunk splitting — if Rollup splits chunks differently between builds, names drift. Fix that with option 3.

3. Pin your manual chunks (most robust for ALM)

The real culprit is often Rollup's automatic code splitting producing differently-named dynamic chunks. Lock it down with manualChunks:

export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        entryFileNames: `assets/[name].js`,
        chunkFileNames: `assets/[name].js`,
        assetFileNames: `assets/[name].[ext]`,
        manualChunks: {
          // Pin vendor libs into a stable named chunk
          vendor: ['react', 'react-dom'],
          // Add other large deps as needed
          // router: ['react-router-dom'],
        },
      },
    },
  },
});

This way Rollup won't invent new chunk names — you've explicitly defined the boundaries.

4. Disable code splitting entirely (nuclear option)

If the SPA is small enough, just bundle everything into one file:

export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        inlineDynamicImports: true, // single bundle
        entryFileNames: `assets/index.js`,
        assetFileNames: `assets/[name].[ext]`,
      },
    },
  },
});

Recommended approach for Power Pages

In the end I've decided to combine options 1+3, that work for my needs.
Considering that I'm using the following libraries:

fluentui: for ui components of my website
react-router-dom: to handle url routing in my SPA
powerbi-client-react: to embed powerbi reports on the site
react-google-charts: for home page charts
adal-angular: to manage authentication

This is (part of) my vite.config.ts:

export default defineConfig({
  plugins: [react()],
  base: '/', // absolute path - Power Pages handles routing
  build: {
    ...
    rollupOptions: {
      output: {
        entryFileNames: `assets/[name].js`,
        chunkFileNames: `assets/[name].js`,
        assetFileNames: `assets/[name].[ext]`,
        manualChunks: {
          router: ['react-router-dom'],
          fluent: ['@fluentui/react-components', '@fluentui/react-icons'],
          powerbi: ['powerbi-client-react'],
          charts: ['react-google-charts'],
          adal: ['adal-angular'],
        },
      },
    },
  },
  ...
});

This gives me a fixed, known set of filenames that map 1:1 to my Power Pages Web Files, and they only change if you explicitly add a new manualChunks group.

🧹 B. Good, but now how I get rid of the old files?

A small hint on how to fix it is given by pac pages upload-code-site command itself. When you run it, it says:

Found 10 bundle pattern(s) to match for cleanup:
1. main .*. js
3. vendor .*. js
4. vendor .*. css
5. chunk -*. js
6. chunk -*. css
7. bundle .*. js
8. bundle .*. css
9. index -*. js
10. index -*. css

Note: You can customize these patterns by adding 'bundleFilePatterns' array in 'powerpages.config.json' file.

So, even if isn't documented anywhere, it seems it tries to clean up the mess before pushing, and it seems we can tweak the powerpages.config.json file to customize it's behavior. After a few tests, I've found that if you add a bundleFilePatterns node with an array of file patterns, those are "pruned" by pac pages upload-code-site before being replaced by the new bundles generated from your build.

In my case, the configuration that works is the following:

{
  "siteName": "my-site-name",
  "defaultLandingPage": "index.html",
  "compiledPath": ".\\dist",
  "bundleFilePatterns": [
    "main.*.js",
    "vendor.*.js",
    "vendor.*.css",
    "chunk-*.js",
    "chunk-*.css",
    "bundle.*.js",
    "bundle.*.css",
    "index-*.js",
    "index-*.css",
    "index.*.js",
    "index.*.css",
    "FluentSystemIcons-Filled.*.woff2",
    "FluentSystemIcons-Filled.*.woff",
    "FluentSystemIcons-Filled.*.ttf",
    "FluentSystemIcons-Light.*.woff2",
    "FluentSystemIcons-Light.*.woff",
    "FluentSystemIcons-Light.*.ttf",
    "FluentSystemIcons-Regular.*.woff2",
    "FluentSystemIcons-Regular.*.woff",
    "FluentSystemIcons-Regular.*.ttf",
    "FluentSystemIcons-Resizable.*.woff2",
    "FluentSystemIcons-Resizable.*.woff",
    "FluentSystemIcons-Resizable.*.ttf"
  ]
}

And it works... it effectively removes all stale files from your local .powerpages-site folder, and when pushed to Dataverse, those file are removed from there as well... or at least, 90% of them.

🖖🏼 C. Let's finish by hand

Even after tweaking the vite.config.ts and the powerpages.config.json, I've found a few files that still remain on my Dataverse environment.

Frankly I think it's a bug of PAC CLI. The only solution I've found is to remove them manually, hoping they won't be re-generated again thanks to

Please note: when you do it, you may occur in the following non-blocking-error while running:

XRM Network error: An error occurred in the PowerPageComponentDeletePlugin.

The only solution I've found to solve this issue is to edit manually the file called .portalconfig/my-site-url-manifest.yml.

You need to:

use Plugin Trace Viewer XrmToolBox Plugin to get all exceptions coming from plugin Microsoft.PowerPages.Core.Plugins.PowerPageComponentDeletePlugin
from the trace message, extract the GUID of the missing component.

search for that GUID into file .portalconfig/my-site-url-manifest.yml and remove the yaml section referring to it. It should be similar to the following.

# sample block to remove
- RecordId: f9d754fb-4b71-4491-bad7-7c06eb21bce5
  DisplayName: index.COcDBgFa.css
  CheckSum: fa7ab4d0d9716e5ae809c29050b94cdaf004c4c51e1f35241716333b1352fb4a
  IsDeleted: false

You may also want to find all lines with IsDeleted: true and remove them, and also clear the contents of the .portalconfig/manifest.yml file (that contains only references to deleted files).

🎯 Final considerations

Power Pages SPA is a huge step forward compared to the classic portal model, especially if you come from a modern frontend background. Being able to bring your own React stack, use Vite, and rely on tools like GitHub Copilot dramatically changes the developer experience and the delivery speed.

That said, today’s reality is that Power Pages SPA is still a young product. Some important behaviors — like how bundles are handled, how cleanup works, and how Dataverse Web Files are managed over time — are either underdocumented or not documented at all. As a result, production-ready solutions still require a fair amount of experimentation, reverse‑engineering, and sometimes even manual intervention.

The chunking issue described in this article is a perfect example:
nothing is technically broken, but without deterministic filenames and explicit cleanup rules, you end up with a slowly degrading site definition, polluted by stale Web Files that get deployed across environments and make ALM harder than it should be.

My personal takeaway so far is:

Treat the build output as a contract: Stable filenames and pinned chunks are not optional in enterprise scenarios — they’re a prerequisite.
Assume PAC CLI cleanup is best‑effort, not authoritative: bundleFilePatterns helps a lot, but today it doesn’t guarantee a 100% clean state.
Expect to occasionally "drop below the abstraction": Editing manifests and cleaning Dataverse artifacts by hand shouldn’t be necessary — but right now, it sometimes is.

Despite all of this, I still strongly believe Power Pages SPA is the right direction. The flexibility it gives you largely outweighs the current rough edges, especially if you’re already comfortable with React, modern bundlers, and CI/CD pipelines.

Hopefully, future iterations of the platform — and better documentation — will make many of the workarounds shown here obsolete. Until then, knowing where the sharp edges are is the key to using this technology effectively.

In the next articles of this series, I’ll dive into other real-world issues and patterns I’ve encountered while building Power Pages SPAs — from authentication quirks, to CSP constraints, to deployment strategies that actually scale.

Stay tuned 🚀

Simple, but yet rock hard, truth.

Riccardo Gregori — Mon, 02 Mar 2026 22:20:43 +0000

The Hardest Part of Being a Developer Isn’t Coding. It’s Disappearing Quietly.

NorthernDev ・ Feb 28

#discuss #mentalhealth #webdev #career

Greg.KeySub – The Ultimate Revenge Against the Italian Keyboard

Riccardo Gregori — Mon, 09 Feb 2026 21:42:04 +0000

There’s a group of people who have been silently suffering for years.
A forgotten minority, ignored by institutions, abandoned by the tech industry, left behind even by Microsoft, Apple, and the United Nations.

I’m talking about us: Italian developers forced to use the Italian keyboard layout.

Yes, that one.

The one that gives you the incredibly useful “§” key, which you have never pressed voluntarily in your entire life, but denies you the most fundamental character of the modern software era:

The backtick: `

The backbone of Markdown.
The unsung hero of code snippets.
The vital organ of shell commands.
A character so essential that GitHub should send you a condolence letter every time you try to write documentation with an Italian keyboard.

The Italian layout? It simply forgot it. Oh, but it has plenty of "useful" keys such as "§" or "ç"...

Every Italian developer has faced at least one of the following situations:

Typing ALT+96 with the elegance of a musician playing the piano with their elbows.
Juggling with WIN+. > move to chars > select the `
Googling “backtick” just to copy and paste the damn symbol.

So… I decided to stop suffering.

I did what any developer does when reality refuses to cooperate:
I wrote a tool to bypass reality entirely. Or better, I vibe coded a tool to save me hours per week.

Introducing: Greg.KeySub

Available here:

👉 https://github.com/neronotte/Greg.KeySub

Greg.KeySub is a tiny Windows tool that quietly lives in your system tray — right next to a few utilities, five unnecessary Electron apps, and three icons whose meaning you’ve forgotten years ago.

Its one and only job?

Listen to the keys you press, and whenever you hit that useless §, it magically transforms it into a glorious, essential, life-improving `.

Yes, you read that right: § becomes `.

Because that key had no purpose. None.
Now, finally, it serves a higher mission.

Why You Should Install It Right Now

🎯 Because it saves time.
Write Markdown like a normal person, not like someone performing finger acrobatics.

🔥 Because it gives purpose to a key that had none.
Digital recycling at its finest.

😤 Because the Italian keyboard layout will never fix itself.
Let’s be honest. It’s been decades. It’s not happening.

⭐ Because it’s open source.
You can contribute, improve it, fork it, or just stare at the code thinking “I would’ve done it differently.”

Install it, try it, love it ❤️

Find it here:

👉 https://github.com/neronotte/Greg.KeySub

If you’re an Italian programmer who writes Markdown, this tool is like that 4 PM coffee: You didn’t know you needed it until you started using it.

Modern Power App development takes a lot of... SPACE.

Riccardo Gregori — Tue, 20 Jan 2026 22:03:37 +0000

🧠 The Paradigm Shift: Why We Don’t Argue UI Anymore

There was a time (you remember it) when any client request that drifted outside the "blessed" Power Apps patterns triggered a long conversation about platform constraints. We tried to reshape requirements, push standard controls, and hope stakeholders would accept a slightly clunky interaction with the UI in the name of long-term maintainability.

That era is over.

With AI-assisted development (hello my dear friend, GitHub Copilot), it’s now faster and safer to build small, targeted customizations—PCFs or React WebResources—than to litigate UX.

You can ship exactly what the client envisions, document it properly, and make it maintainable long-term. The payoff is huge: better UX → higher adoption → stronger platform stickiness. In other words, great UI is not a "nice-to-have"—it’s a retention strategy.

When you replace “discuss why we can’t” with “deliver what delights,” you:

Earn trust faster
Accelerate sign-off
Anchor the customer to the platform with experiences they love

But there’s a catch…

🧱 The Problem: A Dozen PCFs/WebResources = Disk Space Meltdown

React-based PCFs and WebResources lean on Node’s ecosystem. And Node’s ecosystem leans on… node_modules—the folder that eats hard drives for breakfast.

Every project carries its own dependency tree. Multiply that across 8, 12, 20 PCFs/WebResources… and your laptop screams. It’s common to see hundreds of thousands of files and tens (or hundreds) of GB consumed across projects.

Good news: there’s a clean, robust solution that many Power Platform devs underuse:

🧩 The Hidden Gem: NPM Workspaces

NPM Workspaces let you manage multiple packages/projects (PCFs/WebResources) under one repository, sharing a single top-level node_modules whenever possible. This dramatically reduces duplication and makes dependency management more predictable and CI-friendly.

Official docs: NPM Workspaces

What you get:

✅ One central node_modules (plus small per-package shims when needed)
✅ Shared tooling (TypeScript config, lint rules, build scripts)
✅ Shared local packages (@types/xrm, @fluentui/react-components) used across PCFs/WRs via workspace:
✅ Unified scripts (build, test, lint) across all packages
✅ Faster CI with a single dependency tree and cache

🤔 How Does It Works?

It's quite straightforward. All you need is to define a package.json and a package-lock.json files at the root of your project folder, just above the folders containing PCFs and WebResources. This will make your project folder a monorepo.

📂 my-monorepo/
├─ 📄 package.json         <-- workspace root
├─ 📄 package-lock.json
│
├─ 📂 Pcf/
│  ├─ 📂 pcf1/
│  │  ├─ 📄 package.json
│  │  └─ ...
│  └─ 📂 pcf2/
│     ├─ 📄 package.json
│     └─ ...
│
└─ 📂 WebResources/
   ├─ 📂 webresource1/
   │  ├─ 📄 package.json
   │  └─ ...
   └─ 📂 webresource2/
      ├─ 📄 package.json
      └─ ...

It is important that the root package.json file contains the following:

{
  "name": "my-monorepo",
  "private": true,
  "workspaces": [
    "Pcf/*",
    "WebResources/*",
  ]
}

You can do it manually, or via:

cd my-monorepo
npm init -y

npm pkg set private=true
npm pkg set workspaces[0]="Pcf/*"
npm pkg set workspaces[1]="WebResources/*"

Then you can create your PCFs into the PCF and WebResources folder as usual... Just a tip: remember that the value of the name node of the package.json files under each of your PCFs/WRs must be unique, otherwise you'll get an error while running npm <whatever>.

When you'll run

npm install

All dependencies will be installed in a single, above all, node_modules folder created just under the my-monorepo folder.

NOTE: If two packages need different versions of the same dep, npm may place some deps locally. That’s fine; you’ll still save tons of space overall.

🗂️ A Practical Folder Structure for Power Platform Projects

Here’s a realistic example of the output folder you'll get, on a standard Power App project:

📂 project-folder
├─ 📄 .gitignore
├─ 📂 src
│  ├─ 📄 package.json
│  ├─ 📄 package-lock.json
│  ├─ 📂 node_modules
│  ├─ 📂 Pcf
│  │  ├─ 📂 NumericInputControl
│  │  │  ├─ 📄 package.json
│  │  │  ├─ 📄 package-lock.json
│  │  │  └─ ...
│  │  ├─ 📂 PurchaseOrderGrid
│  │  │  ├─ 📄 package.json
│  │  │  ├─ 📄 package-lock.json
│  │  │  └─ ...
│  │  └─ 📂 CustomTreeView
│  │     ├─ 📄 package.json
│  │     ├─ 📄 package-lock.json
│  │     └─ ...
│  └─ 📂 WebResources
│     ├─ 📂 HomePage
│     │  ├─ 📄 package.json
│     │  ├─ 📄 package-lock.json
│     │  └─ ...
│     └─ 📂 ControlDashboard
│        ├─ 📄 package.json
│        ├─ 📄 package-lock.json
│        └─ ...
└─ 📂 test
   └─ ... # other stuff

📉 How Much Space Do You Actually Save?

In Power Platform solutions with 8–20 React packages, we’ve seen:

60–80% reduction in duplicated dependency files
Build times drop (less overall I/O and fewer cold installs)

Your mileage varies with library choices, but the direction is always the same: less bloat, more flow.

🪄 Conclusions

AI copilot tools make building custom, crisp UX easy. NPM Workspaces make maintaining many customizations sane. Put them together and you’ve got a Power Platform development lifecycle that’s fast, clean, and—dare I say—fun.

Give it a try, and let me know in the comments what you think about it!

Automatically Refresh Forms After Status Changes in Model Driven Apps

Riccardo Gregori — Fri, 26 Dec 2025 14:16:52 +0000

When designing complex state models in Model Driven Apps, sometimes it can happen you need to "freeze" the possibility for the user to update a record data while some operation runs in background, and then make it editable again when the operation completes.

A few practical examples:

Document Generation and E-signature: A quote record triggers automatic PDF generation and sends it to DocuSign or Adobe Sign. While the document is being generated, sent, and awaiting signature, the contract terms should be locked. Once the signature is complete (or rejected), the form becomes editable again for next steps.
Credit Check Integration: When a customer service rep creates a new customer account, an external credit check service is called in the background. The form needs to be frozen while waiting for the credit score, payment terms recommendations, and risk assessment to return. You don't want users changing customer details while the credit bureau is still processing the original information.
Inventory Reservation in Order Processing: When an order is placed, a background process checks inventory across multiple warehouses and reserves stock. During this reservation process (which might involve calling external warehouse management systems), the order quantities should be frozen to prevent overselling or conflicts.
Compliance and Regulatory Checks: In healthcare or financial services, when a case is submitted, it might trigger automated compliance screenings (sanctions lists, fraud detection, regulatory reporting). The case details must remain locked during these checks to maintain audit trail integrity.
Data Enrichment from Third-party APIs: A lead record triggers enrichment processes pulling company data from LinkedIn, Clearbit, or Dun & Bradstreet. While these APIs are called and data is being validated and merged, you want to prevent users from manually entering conflicting information.

Typically, you can leverage the out of the box statecode and statuscode fields of the interested table to model the frozen statuses. If we take for instance the first example above, a possible state model for the quote table can be the following:

Logical Status	`statecode`	`statuscode`	Description
New	Active	New	The quote is being created and filled with data
Submitted	Inactive	Submitted	The quote has been submitted for the digital signature, the background operation is running
Signed	Active	Signed	The quote is open for post-signature steps (approvals, project generation, etc)
Cancelled	Inactive	Cancelled	The quote has been logically removed from the system
Sent	Inactive	Sent	Quote sent to the client
Won	Inactive	Won	The client accepted the quote
Lost	Inactive	Lost	The client has rejected the quote

Where the meaning of the statecode=Inactive is "not updatable by the user". I often prefer to change the label of that state to "Read only", as I find this wording less misleading and more intuitive.

If the trigger that changes the status to the inactive one comes from the form, we have a small UX problem: the form will be disabled (as required), the operation will run in the background (as required), but when the operation ends (after a couple of seconds, potentially), the user doesn't have any clue about the completeness. He needs to manually trigger the form refresh to see the changes to the current record.

Of course you can leverage MDA Push Notification system in the async workflow to notify the user but... he still needs to reopen the record to see the changes.

Fixing this UX issue is quite easy, you can just add a few lines of JavaScript in the form that:

runs only when the status changes to the inactive one you want to monitor
checks iteratively via WebApi for the status to change
when the status changes, refreshes the form data.

just like the following one:

class Form {
    formType = {
        Create: 1,
        Update: 2,
        ReadOnly: 3,
        Disabled: 4,
        BulkEdit: 6
    };

    statuscode = {
        New: 1,
        Submitted: 2
    }

    // Polling interval for status monitoring
    pollingInterval = null;

    onLoad(executionContext) {
        const formContext = executionContext.getFormContext();
        const formType = formContext.ui.getFormType();

        // Start auto-refresh monitoring if status is Submitted
        const status = this.statuscode.Submitted;
        this.startStatusMonitoring(formContext, status);
        formContext.data.addOnLoad(() => {
            this.startStatusMonitoring(formContext, status);
        });
    }

    /**
     * Starts monitoring the record status if it's in Initializing state
     * @param {object} formContext - The form context
     */
    startStatusMonitoring(formContext, status) {
        const currentStatus = formContext.getAttribute("statuscode").getValue();

        // Only start monitoring if status is Submitted
        if (currentStatus !== status) {
            return;
        }

        console.log("Starting status monitoring for Initializing record");

        // Clear any existing interval
        if (this.pollingInterval) {
            clearInterval(this.pollingInterval);
        }

        // Start polling every 2 seconds
        this.pollingInterval = setInterval(async () => {
            try {
                await this.checkStatusChange(formContext, status);
            } catch (error) {
                console.error("Error checking status change:", error);
                // Continue polling even if there's an error
            }
        }, 2000);
    }

    /**
     * Checks if the record status has changed and refreshes the page if it has
     * @param {object} formContext - The form context
     */
    async checkStatusChange(formContext, status) {
        const recordId = formContext.data.entity.getId().replace(/[{}]/g, "");
        const entityName = formContext.data.entity.getEntityName();

        try {
            // Retrieve the current statuscode from the server
            const result = await Xrm.WebApi.retrieveRecord(entityName, recordId, "?$select=statuscode");
            const serverStatus = result.statuscode;
            const currentFormStatus = formContext.getAttribute("statuscode").getValue();

            console.log(`Current form status: ${currentFormStatus}, Server status: ${serverStatus}`);

            // If status has changed from Submitted, refresh the page
            if (currentFormStatus === status && serverStatus !== status) {
                console.log("Status changed, refreshing page...");

                // Clear the polling interval
                this.stopStatusMonitoring();

                // Refresh the current window
                formContext.data.refresh();
            }
        } catch (error) {
            console.error("Failed to retrieve record status:", error);
            // Don't stop polling on API errors, as they might be temporary
        }
    }

    /**
     * Stops the status monitoring (useful for cleanup)
     */
    stopStatusMonitoring() {
        if (this.pollingInterval) {
            clearInterval(this.pollingInterval);
            this.pollingInterval = null;
            console.log("Status monitoring stopped");
        }
    }
}

Greg = window.Greg || {};
Greg.greg_quote = Greg.greg_quote || {};
Greg.greg_quote.Form = new Form();

Hope this helps you too!

How to: Fix WebResources Layout in Dataverse Dashboards

Riccardo Gregori — Tue, 18 Nov 2025 22:59:07 +0000

🤔 The problem

If you ever managed to create a Dataverse Dashboard containing an HTML WebResource (e.g. to show some calculated KPI), by default the resulting UI is quite ugly:

What I don't like:

Each WebResource component has a surrounding black border I would like to get rid of
The minimum vertical space that can be occupied by the WebResources row is 6 lines. Too much for my needs.

For both points, the Dashboard editor doesn't provides any option to fix the problem:

No option to remove the border

And I cannot reduce the vertical space

💡 The solution

As usual, the solution is quite simple via small XML tweaking.

Step 1. Create a new solution

In my case I already had a "ribbon" solution ready to use, thus in the screenshots below you'll see that one.

Step 2. Add the dashboard as the only component

Access the solution, then click on Add existing > Dashboard

And peek the dashboard you want to update (in my case, Tickets).

Step 3. Move to VS Code

In VSCode terminal, run the following PAC CLI command:

pac solution clone --name "<your solution unique name>"

PAC CLI will automatically download the solution and unpack its components in the current folder.

Step 4. Update the Dashboard XML definition

Access the dashboard xml definition you'll find at <solution name>\src\Dashboards\<dashboard guid>.xml

In the XML definition, find the WebResources controls. They can be easily found searching by the following string <control id="WebResource_.

You'll see something like this:

<cell colspan="1" rowspan="6" showlabel="false" id="{77846b48-5139-4c61-a5d1-fda39d80f21b}">
    <labels>
    <label description="KPI1" languagecode="1033" />
    </labels>
    <control id="WebResource_kpi1" classid="{9FDF5F91-88B1-47f4-AD53-C11EFC01A01D}">
    <parameters>
        <Url>prefix_/pages/dashboardkpi/index.html</Url>
        <Data>ticket_total_count</Data>
        <PassParameters>false</PassParameters>
        <ShowOnMobileClient>false</ShowOnMobileClient>
        <Security>false</Security>
        <Scrolling>auto</Scrolling>
        <Border>true</Border>
        <WebResourceId>{F30B702C-C9C4-F011-BBD3-7CED8D454E57}</WebResourceId>
    </parameters>
    </control>
</cell>

To remove the border, update the <Border> node to false.
To decrease the height, set the rowspan attribute to 3 (or adjust it as you wish).

Like this:

<cell colspan="1" rowspan="3" showlabel="false" id="{77846b48-5139-4c61-a5d1-fda39d80f21b}">
    <labels>
    <label description="KPI1" languagecode="1033" />
    </labels>
    <control id="WebResource_kpi1" classid="{9FDF5F91-88B1-47f4-AD53-C11EFC01A01D}">
    <parameters>
        <Url>prefix_/pages/dashboardkpi/index.html</Url>
        <Data>ticket_total_count</Data>
        <PassParameters>false</PassParameters>
        <ShowOnMobileClient>false</ShowOnMobileClient>
        <Security>false</Security>
        <Scrolling>auto</Scrolling>
        <Border>false</Border>
        <WebResourceId>{F30B702C-C9C4-F011-BBD3-7CED8D454E57}</WebResourceId>
    </parameters>
    </control>
</cell>

Step 5. Rebuild the solution in unmanaged mode

Open the terminal in the folder containing the <solution>.cdsproj file and run the following command:

dotnet build

it will generate the unmanaged version of the solution in the \bin\Debug subfolder of the current folder.

Step 6. Import the generated solution

Via PAC CLI:

# ribbon is the name of my solution, change it with your own
pac solution import -p .\bin\debug\ribbon.zip

Step 7. Publish all

This time, let's use PACX

pacx publish all

You can always do it the old way, via maker portal

😎 The result

Et voilà, the same dashboard, with both issues fixed ☺️

Hope this helps you too!

Model Driven App: disable "Open in Excel Online" button

Riccardo Gregori — Thu, 13 Nov 2025 16:17:20 +0000

🤔 The issue

The out-of-the-box Excel integration in Model Driven apps is a powerful, but very dangerous, feature.

Import from Excel, especially, can be very harmful because an user could leverage it to bypass any client side logic put on forms, generating inconsistent data within the system. Moreover, it cannot be customized: you cannot say "you can import opportunities records, but you cannot import accounts", neither you could say "import works only on columns A, B, C".

That's the reason why, in most of the CRM (and MDAs) implementations I've seen so far, the Import from Excel button is disabled for standard users, and replaced with custom data-import capabilities.

Disabling the Import from Excel button is quite easy, It just requires from you to remove the Data Import and Data Map privileges from the role assigned to users.

It works... more or less...

...even if the Data Import privilege is removed, you can have the possibility to open the "Export In Excel" > "Open in Excel Online" capability

With the edit capability enabled, and the Save button visible and clickable:

If you change something and click on Save, the following (ugly) error message appears (depending on the UI language of the user, mine is Italian)

That's a behavior that looks more like a bug than a feature, IMHO.

The best would be to disable that "Open in Excel Online" button too... tipically for specific users/roles. But there is no such option in the role privileges...

😖 Failed fix tentatives

If you try to hide the button using Ribbon Workbench or the Modern Ribbon editor, you will quickly see that's any customization on that button is disabled.

👍🏻 How to do it

For people like me, mold by CRM implementations before Ribbon Workbench, the fix is quite straightforward: let's tweak the RibbonDiffXml "the old way".

First of all, let's create a solution containing only the definition of the entity we want to disable that button for.

Then let's use Power Platform CLI commands to export and unpack the solution in a local folder

pac solution clone --name temp

It generates locally a structure similar to the following:

Let's open the RibbonDiff.xml file, it will be like the following one:

<?xml version="1.0" encoding="utf-8"?>
<RibbonDiffXml xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <CustomActions />
  <Templates>
    <RibbonTemplates Id="Mscrm.Templates"></RibbonTemplates>
  </Templates>
  <CommandDefinitions />
  <RuleDefinitions>
    <TabDisplayRules />
    <DisplayRules />
    <EnableRules />
  </RuleDefinitions>
  <LocLabels />
</RibbonDiffXml>

In the <DisplayRules> node, let's add a rule that is evaluated to "true" only in the case an user is system administrator (here you can use your fantasy)...

<DisplayRules>
  <DisplayRule Id="greg.tablename.IsSystemAdmin.DisplayRule">
    <EntityPrivilegeRule PrivilegeType="Delete" PrivilegeDepth="Basic" EntityName="solution" Default="false" InvertResult="false" />
  </DisplayRule>
</DisplayRules>

Then, in the <CommandDefinitions> node, let's add the following

<CommandDefinitions>
  <CommandDefinition Id="Mscrm.ExportToExcel.Online">
    <EnableRules>
      <EnableRule Id="Mscrm.ExportToExcel.ValidForXlsxExport" />
      <EnableRule Id="Mscrm.EnableExportToExcelOnlineForModern" />
      <EnableRule Id="Mscrm.EnableOnlyInBrowsersForModern" />
    </EnableRules>
    <DisplayRules>
      <DisplayRule Id="Mscrm.Live" />
      <DisplayRule Id="Mscrm.IsExportToExcelFCBEnabled" />
      <DisplayRule Id="Mscrm.HideOnOutlookClient" />
      <DisplayRule Id="Mscrm.NotAdvancedFind" />
      <DisplayRule Id="Mscrm.HideOnPhoneForNonModern" />
      <DisplayRule Id="Mscrm.HideForTabletExperience" />
      <DisplayRule Id="greg.tablename.IsSystemAdmin.DisplayRule" />
    </DisplayRules>
    <Actions>
      <JavaScriptFunction FunctionName="XrmCore.Commands.Export.exportToExcel" Library="$webresource:Main_system_library.js">
        <CrmParameter Value="SelectedControl" />
        <CrmParameter Value="SelectedEntityTypeName" />
        <IntParameter Value="6" />
      </JavaScriptFunction>
    </Actions>
  </CommandDefinition>
</CommandDefinitions>

The final RibbonDiffXML should look something similar to the following:

<?xml version="1.0" encoding="utf-8"?>
<RibbonDiffXml xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <CustomActions />
  <Templates>
    <RibbonTemplates Id="Mscrm.Templates"></RibbonTemplates>
  </Templates>
  <CommandDefinitions>
    <CommandDefinition Id="Mscrm.ExportToExcel.Online">
      <EnableRules>
        <EnableRule Id="Mscrm.ExportToExcel.ValidForXlsxExport" />
        <EnableRule Id="Mscrm.EnableExportToExcelOnlineForModern" />
        <EnableRule Id="Mscrm.EnableOnlyInBrowsersForModern" />
      </EnableRules>
      <DisplayRules>
        <DisplayRule Id="Mscrm.Live" />
        <DisplayRule Id="Mscrm.IsExportToExcelFCBEnabled" />
        <DisplayRule Id="Mscrm.HideOnOutlookClient" />
        <DisplayRule Id="Mscrm.NotAdvancedFind" />
        <DisplayRule Id="Mscrm.HideOnPhoneForNonModern" />
        <DisplayRule Id="Mscrm.HideForTabletExperience" />
        <DisplayRule Id="greg.tablename.IsSystemAdmin.DisplayRule" />
      </DisplayRules>
      <Actions>
        <JavaScriptFunction FunctionName="XrmCore.Commands.Export.exportToExcel" Library="$webresource:Main_system_library.js">
          <CrmParameter Value="SelectedControl" />
          <CrmParameter Value="SelectedEntityTypeName" />
          <IntParameter Value="6" />
        </JavaScriptFunction>
      </Actions>
    </CommandDefinition>
  </CommandDefinitions>
  <RuleDefinitions>
    <TabDisplayRules />
    <DisplayRules>
      <DisplayRule Id="greg.tablename.IsSystemAdmin.DisplayRule">
        <EntityPrivilegeRule PrivilegeType="Delete" PrivilegeDepth="Basic" EntityName="solution" Default="false" InvertResult="false" />
      </DisplayRule>
    </DisplayRules>
    <EnableRules />
  </RuleDefinitions>
  <LocLabels />
</RibbonDiffXml>

Now build the solution ad upload the generated solution zip file:

dotnet build
pac solution import --path .\bin\debug\temp.zip

Wait for the import to complete, then go to your environment, select the solution you just uploaded, and click Publish All Customizations.

Or, if you're using PACX in your project, simply type:

pacx publish all

That's it... Now that button will be visible only by System Administrator.

Hope this helps you too!

Dataverse MCP Server configuration failed...

Riccardo Gregori — Thu, 06 Nov 2025 20:35:04 +0000

If you want to configure the Dataverse MCP Server as described in the official Microsoft Learn article, you'll need to write in your mcp.json file an url with the following exact format (without the line breaks, of course):

https://make.powerautomate.com/environments/
59fd5b0e-f1e3-4f86-920d-509f44cb1846/connections
?apiName=shared_commondataserviceforapps
&connectionName=263a3d1e-1279-45f6-a593-070f9efaaad3

The tutorial instructs you to create a connection via make.powerautomate.com, and then take the URL from the connection page.

If you do it exactly as stated in the official docs, the URL you'll get has this form:

https://make.powerautomate.com/environments/
59fd5b0e-f1e3-4f86-920d-509f44cb1846/connections
/shared_commondataserviceforapps
/263a3d1e-1279-45f6-a593-070f9efaaad3/details

The fact is that URL, put in the mcp.json file, won't work 😡🤬.

You need to tweak the url manually in the following way:

take the first part of the url, from https:// to connections
replace the / after connections with ?apiName=
replace the / after shared_commondataserviceforapps with &connectionName=
remove the leading /details

And you're ready to go.

🙏🏻 Hope this helps you too!

Forem: Riccardo Gregori

PCF's default Fluent UI version is broken... and how to fix it

⚙️ The Setup

❌ The Crash

🔨 The Fix

🧐 Takeaways

Power Pages SPA, local authentication, and the "Private" flag that blocks local development

📖 Background: Power Pages SPA

🔗 The constraint: local authentication

🧱 The authentication stack

🐛 The problem: the wrong redirect_uri

🔍 The search for a solution

✅ The solution

📝 A note on the documentation

⚙️ Operational notes

🧐 Conclusions

Vibe coded Power Pages SPA: unfiltered

💡 Let's start with the idea

💻 Let's build the backend

🤔 My personal opinion on this step

🔗 Let's wire things up

🤔 My personal opinion on this step

✍🏻 Create sample data

📦 One more to go: deploy

☺️ Conclusions

ALM on Power Platform: ADO + GitHub, the best of both worlds

TL;DR

🏗️ The starting point: Azure DevOps as the backbone

🎮 New App types are changing the rules of the game

💎 GitHub is more than just a repository

🔗 The hybrid setup: ADO + GitHub integrated

↔️ The bidirectional link in commits

🤖 The Copilot Cloud Agent: a collaborator that works while you sleep

🎯 Contextual review, not generic feedback

Final thoughts

Power Pages SPA Learning By Doing - Keep it clean

🤔 The issue - Stale files generated by chunking strategy

💡 How to fix it?

📌 Step A. Apply deterministic names on chunks

1. Disable hashing entirely (simplest)

2. Use a fixed/stable hash (content-based, but stable)

3. Pin your manual chunks (most robust for ALM)

4. Disable code splitting entirely (nuclear option)

Recommended approach for Power Pages

🧹 B. Good, but now how I get rid of the old files?

🖖🏼 C. Let's finish by hand

🎯 Final considerations

Simple, but yet rock hard, truth.

The Hardest Part of Being a Developer Isn’t Coding. It’s Disappearing Quietly.

NorthernDev ・ Feb 28

Greg.KeySub – The Ultimate Revenge Against the Italian Keyboard

Introducing: Greg.KeySub

Why You Should Install It Right Now

Install it, try it, love it ❤️

Modern Power App development takes a lot of... SPACE.

🧠 The Paradigm Shift: Why We Don’t Argue UI Anymore

🧱 The Problem: A Dozen PCFs/WebResources = Disk Space Meltdown

🧩 The Hidden Gem: NPM Workspaces

🤔 How Does It Works?

🗂️ A Practical Folder Structure for Power Platform Projects

📉 How Much Space Do You Actually Save?

🪄 Conclusions

Automatically Refresh Forms After Status Changes in Model Driven Apps

How to: Fix WebResources Layout in Dataverse Dashboards

🤔 The problem

💡 The solution

😎 The result

Model Driven App: disable "Open in Excel Online" button

🤔 The issue

😖 Failed fix tentatives

👍🏻 How to do it

Dataverse MCP Server configuration failed...

🐛 The problem: the wrong `redirect_uri`