Forem: Riccardo Gregori

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!

💵 Dataverse Exchange Rates 101 💵

Riccardo Gregori — Mon, 03 Nov 2025 10:31:37 +0000

See the original post from Sabih Ahmed Khan

In Dynamics 365, exchange rates are not always recalculated automatically:

🔹 When Exchange Rate IS Applied

At the moment a record with currency fields is created.
When a money column in the record is updated.
When the state of the record changes (e.g., draft → submitted).

🔹 When Exchange Rate is NOT Applied

Simply changing a non-money field (like quantity) doesn’t trigger recalculation.
Viewing a record later still shows values based on the exchange rate at the time it was last assigned, not the latest rate.
Currency updates in the system don’t retroactively update existing records.

💡 Takeaway: Exchange rates are point-in-time values unless the record’s money fields or state are updated.

If you want to properly manage exchange rate values, see my previous blog post Update currency Exchange Rate in Dataverse... simplified! 😊

Generative Pages: The Right Hype, for the Wrong Reason

Riccardo Gregori — Sat, 25 Oct 2025 15:51:04 +0000

Lately, the Power Platform community has been buzzing with excitement over Generative Pages. Touted as a game-changer, they’re often presented as the long-awaited solution for building custom interfaces within Model-Driven Apps. And while the enthusiasm is understandable, I can’t help but feel that the hype is—at least partially—misplaced.

Let me explain.

🦄 The Myth: “Finally, Custom UI in Model-Driven Apps!”

A recurring narrative I’ve seen is that Generative Pages are being celebrated as the first real way to build custom UIs in Model-Driven Apps. But for those of us who’ve been around since the Dynamics CRM days, this isn’t exactly new territory.

We’ve always had the ability to create custom interfaces using HTML WebResources. Whether it was jQuery in the early days or more modern stacks like React + TypeScript + Fluent UI, the platform has long supported advanced UI customization. The only difference? Back then, you had to roll up your sleeves and build it yourself.

🔍 The Reality: Generative Pages Are a New Abstraction, Not a New Capability

Generative Pages are a fantastic addition—don’t get me wrong. They lower the barrier to entry, especially for makers and newcomers who might not be familiar with the extensibility model of Dataverse. But they’re not a replacement for pro-code solutions. They’re a new abstraction layer, not a new frontier.

If you’re looking for true flexibility, performance, and control, custom WebResources still reign supreme. And if you’re wondering how to get started with those, I’ve written extensively on the topic:

Dataverse Web Resources with React, Typescript and FluentUI (_neronotte's way)
Form-based Dataverse Web Resources with React, Typescript and FluentUI - Part 1
Form-based Dataverse Web Resources with React, Typescript and FluentUI - Part 2
Say Goodbye to CRA, Hello to Vite - the last but most important, because the previous articles rely on an NPM template that no longer exists.

These posts walk through everything from scaffolding your project to handling context injection and deploying with PACX. They’re not just tutorials—they’re a testament to the maturity and power of the platform’s extensibility model.

And they were written before the Generative AI era. Now you can also leverage GitHub Copilot capabilities in VS or VS Code to implement the logic, making the gap with Generative Pages even lower.

🧪 WebResources vs PCFs: The Debugging and Testing Advantage

Another point that often gets overlooked in the Generative Pages vs. WebResources vs. PCF debate is the developer experience—especially when it comes to debugging and testing.

Compared to PCFs (PowerApps Component Framework), WebResources are significantly easier to debug. You can run them in the browser, inspect them with standard dev tools, and iterate quickly without the need for complex build pipelines or deployment steps. This makes them ideal for rapid prototyping and iterative development.

PCFs, while powerful, come with a steeper learning curve and a more rigid development lifecycle. Debugging often requires attaching to the browser process, dealing with iframes, and managing a more complex deployment model. For many use cases, especially those that don’t require deep integration with the control lifecycle, WebResources are simply more efficient.

💾 Source Control and DevOps: Still a Win for WebResources

One of the lesser-known advantages of WebResources is how well they integrate with source control and CI/CD pipelines. Thanks to tools like Power Platform CLI and PACX, you can manage your WebResource projects in Git, automate deployments, and maintain a clean, versioned history of your codebase.

This is still a significant advantage over Generative Pages, which—at least for now—lack the same level of DevOps maturity. While Microsoft is making strides in this area, the ability to fully own and manage your codebase remains a key differentiator for WebResources.

🌟 The Real Value Behind Generative Pages

Generative Pages are worth the excitement because they fundamentally shift the accessibility of custom experiences in Model-Driven Apps.

For years, building tailored interfaces meant diving into pro-code solutions like WebResources or PCF—powerful, but often out of reach for makers and business users.

Generative Pages change that equation by introducing an abstraction layer that democratizes UI creation without sacrificing Dataverse integration or solution governance.

They accelerate time-to-value, reduce dependency on specialized front-end skills, and align perfectly with the low-code ethos of Power Platform.

In short, they don’t replace pro-code—they complement it, enabling organizations to deliver functional, data-centric pages faster and with less friction, while still leaving room for deeper customization when needed.

🤔 Final Thoughts

Let’s welcome Generative Pages for what they are: a helpful tool in the toolbox. But let’s also continue to educate and advocate for the powerful capabilities that have been there all along. The Power Platform isn’t just evolving—it’s maturing. And as professionals, it’s our job to guide that evolution with clarity and context.

If you’re serious about building rich, enterprise-grade experiences in Model-Driven Apps, don’t overlook the power of WebResources. They’re not just legacy—they’re battle-tested, flexible, and still incredibly relevant.

Your Dataverse Solutions Deserve Better Builds (Here’s How)

Riccardo Gregori — Sun, 19 Oct 2025 14:22:37 +0000

Based on my personal experience (I have been working on Dynamics CRM / Power Platform since 2009 and have delivered dozens of projects), today a typical middle-sized CRM / Model Driven App project contains:

A data model made of roughly 30 tables.
A few dozen basic Web Resources (images, form JS, command bar JS, theme assets, etc.).
One or more Plugin Packages.
One or more HTML/React Web Resources.
One or more PCF controls.
One or more Power Automate flows (with related Connection References).
One or more Model Driven Apps.
Roles, field security profiles… everything concerning the security model.

This is the typical content of a middle-sized project; obviously there are smaller ones, but also much larger and more complex initiatives, each with its own peculiarities.

Looking at the structure of my typical medium project, over time I have tried to standardize ALM processes, industrializing my delivery approach, with the goal of improving (making more efficient) the way I work and the way the people working with me operate.

🧱 Solutions

This industrialized approach also involves defining the Dataverse solutions that compose the application in a consistent way: I prefer a layered approach where solutions are organized by component type, with a strict and well-defined dependency direction.

1st principle: Each solution contains only and exclusively components that depend on components present in lower-level solutions.

Following the 1st principle, the solutions I typically define are the following:

Layer	Name	Description
1	0100 - WebResources	Contains all project Web Resources (images, form and command bar JS, theme, assets, HTML pages, etc.).
2	0200 - PCF	Contains custom PCF controls implemented for the project.
3	0300 - Data Model	Contains the system data model (tables, columns, forms, views).
4	0400 - Business Logic	Contains Plugin Packages, Steps, Custom APIs, Power Automate flows—everything that is business logic.
5	0500 - Other	Contains apps, sitemaps, security roles(1), and the rest of the solution components.

(1) For roles a specific discussion is needed: if system forms and views depend on roles, then roles go into the Data Model solution; otherwise they go into "Other".

Layering note: the order of the layers is based on import prerequisites (a form may require a Web Resource / PCF already present), not on the functional responsibility flow (UI consuming the data model). Web Resources and PCF controls do not create formal dependencies toward tables/columns until they are attached to forms, so they can be imported earlier.

Naming convention note: Each solution starts with a 4-digit number. The first 2 digits represent the current layer. The second two digits are used when the solution becomes too large and you decide to fragment its content. Example: suppose you have N React Web Resources (which are typically heavier). You might decide to have a separate solution for each one. In that case I would name them:

0100 - WebResources - Base
0101 - WebResources - Home Page
0102 - WebResources - Monitoring Dashboard
0103 - WebResources - Customer Details
…

🔢 Source Versioning

In my projects, both the source code of the custom components I build (Plugins, Web Resources, PCF controls, etc.) and the solutions described earlier—downloaded and unpacked into their minimal components through pac solution sync—are versioned in a Git repository (Azure DevOps / Visual Studio or GitHub, based on client preference).

However, when we download solutions locally to version them, we have a problem: they contain all our customizations, including Web Resources (compiled, in the case of React-based Web Resources) and .nupkg files of our Plugin Packages.

Anyone who has studied ALM theory knows one thing:

2nd principle: The repository must not contain artifacts—only source code.

To avoid storing in the repo what are effectively duplicates of already existing objects (think simple Web Resources) or artifacts (the HTML/JS/CSS of React Web Resources, or plugin .nupkg files), mapping files come to the rescue (we already discussed them in the article "Relative Paths in Solution Mapping Files" and in "When Plugin Packages Break Your Mapping Files (and How to Fix It)").

The rules for composing and incrementing the build version number are described in the "Version Format" paragraph in the Pipeline section.

🧩 And what about PCF?

For the PCF solution the technique I use is slightly different. While in other cases I first create the solution in Dataverse and then obtain a local copy via pac solution clone / pac solution sync, for PCF I:

Create a solution directly locally using pac solution init.
Add the PCF project(s) to the solution as references using pac solution add-reference.
Modify the .cdsproj file adding the PropertyGroup shown below so that I get a Managed solution if I compile in Release mode, and an Unmanaged one if I compile in Debug mode.

<PropertyGroup>
    <SolutionPackageType Condition="'$(Configuration)' == 'Debug'">Unmanaged</SolutionPackageType>
    <SolutionPackageType Condition="'$(Configuration)' == 'Release'">Managed</SolutionPackageType>
    <SolutionFileVersion></SolutionFileVersion>
    <SolutionPackageEnableLocalization>false</SolutionPackageEnableLocalization>
</PropertyGroup>

After that, I just compile the solution in Release mode and push it to Dataverse using pac solution import… and PCF controls are up and running.

🚀 Pipeline

With such an organization of solutions, if we want to manage releases in a deterministic and reproducible way, we should build a build pipeline that performs the following steps:

Define the version number associated with the current build (Build.BuildNumber).
Compile the React Web Resources.
Compile the projects related to plugin DLLs to generate the PluginPackage (.nupkg).
Update the solutions' versions setting them to Build.BuildNumber.
Compile the PCF solution (0200 - PCF) in Release mode.
Compile the remaining Dataverse solutions in Release mode, retrieving:
1. Simple Web Resources from the folder where they reside in the repo.
2. React Web Resources from the folder containing the built output generated in step #2.
3. Plugin packages from the bin\Release subfolder of the corresponding project.

🧮 Version Format

The value used for Build.BuildNumber (or equivalent runner number) must follow the format <major.minor.patch.build>.

The version number of the .nupkg (Plugin Package) is normally not relevant for import: the environment accepts the update as long as existing plugin types/contracts are not broken. However, the version MUST change (major or minor) when one or more plugin classes previously deployed are physically removed; otherwise you risk hitting the following error:

Exception type: System.ServiceModel.FaultException[Microsoft.Xrm.Sdk.OrganizationServiceFault]

Message: Plugin Assemblies import: FAILURE. Error: Plugin: 'NAME OF PLUGIN ASSEMBLY', Version=<0.1.0.0> ... caused an exception.: Existing plug-in types have been removed. Please update major or minor verion of plug-in assembly. ...

🔁 Back to the pipeline

Theoretically implementing such a pipeline seems quite trivial.

In reality, when you try to set it up you hit several problems:

Passing the version number to solutions at compile time (via dotnet build, as we would for any other .NET project) does not work. The version number passed as a parameter is not reflected in the actual solution version. The only way to make the solution actually reflect the current build version is to add a PowerShell script that physically modifies the Solution.xml files, changing the Version node, manually or through the pac solution version command.
Mapping files do not work with Plugin Packages. Or rather… they work during sync, but not during build. You need something that manually copies the .nupkg files generated by compiling the plugin DLLs into the solution folder before building the solution itself.
The .nupkg files generated by the DLL build, moreover, have a different name than expected by the Dataverse solutions. So you also need a rename step "in the middle," before or after the copy.

' Package generated by the DLL project build
Greg.Plugins.1.0.0.nupkg

' "Expected" name by the Dataverse solution
nn_Greg.Plugins.nupkg

I tried N different ways to build a general purpose pipeline that performed all necessary steps, overcoming the problems listed above, but honestly none of the solutions I arrived at ever fully satisfied me.

Too many variables inside the pipeline code.

Too many steps to manually modify project by project.

…until…

🚨 Betim to the rescue 🚨

My friend Betim Beja suggested I try using his project templates, completely open source and available on GitHub.

For me, a turning point.

His AlbanianXrm.CDSProj.Sdk is an SDK-style Visual Studio project template that can be used to replace the standard definition of .cdsproj projects automatically generated by pac solution clone / pac solution sync.

Compared to the "original" Dataverse template, it drastically simplifies managing all the issues I listed above.

⁉️ How to use it

After creating your solution inside Dataverse (manually, or via pacx solution create):

Step 1. Clone the solution locally using pac solution clone.

Step 2. Open the file solutionname.cdsproj, which should look similar to the following:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <PowerAppsTargetsPath>$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\PowerApps</PowerAppsTargetsPath>
  </PropertyGroup>

  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" />
  <Import Project="$(PowerAppsTargetsPath)\Microsoft.PowerApps.VisualStudio.Solution.props" Condition="Exists('$(PowerAppsTargetsPath)\Microsoft.PowerApps.VisualStudio.Solution.props')" />

  <PropertyGroup>
    <ProjectGuid>5aa1879b-b4a3-4734-bcad-d964d642cdff</ProjectGuid>
    <TargetFrameworkVersion>v4.6.2</TargetFrameworkVersion>
    <!--Remove TargetFramework when this is available in 16.1-->
    <TargetFramework>net462</TargetFramework>
    <RestoreProjectStyle>PackageReference</RestoreProjectStyle>
    <SolutionRootPath>src</SolutionRootPath>
  </PropertyGroup>

  <!-- 
    Solution Packager overrides, un-comment to use: SolutionPackagerType (Managed, Unmanaged, Both)
    Solution Localization Control, if you want to enabled localization of your solution, un-comment SolutionPackageEnableLocalization and set the value to true. - Requires use of -loc flag on Solution Clone or Sync
  -->
  <!--
  <PropertyGroup>
    <SolutionPackageType>Managed</SolutionPackageType>
    <SolutionPackageEnableLocalization>false</SolutionPackageEnableLocalization>
  </PropertyGroup>
  -->

  <ItemGroup>
    <PackageReference Include="Microsoft.PowerApps.MSBuild.Solution" Version="1.*" />
    <PackageReference Include="Microsoft.NETFramework.ReferenceAssemblies" Version="1.0.0" PrivateAssets="All" />
  </ItemGroup>

  <ItemGroup>
    <ExcludeDirectories Include="$(MSBuildThisFileDirectory)\.gitignore" />
    <ExcludeDirectories Include="$(MSBuildThisFileDirectory)\bin\**" />
    <ExcludeDirectories Include="$(MSBuildThisFileDirectory)\obj\**" />
    <ExcludeDirectories Include="$(MSBuildThisFileDirectory)\*.cdsproj" />
    <ExcludeDirectories Include="$(MSBuildThisFileDirectory)\*.cdsproj.user" />
    <ExcludeDirectories Include="$(MSBuildThisFileDirectory)\*.sln" />
  </ItemGroup>

  <ItemGroup>
    <None Include="$(MSBuildThisFileDirectory)\**" Exclude="@(ExcludeDirectories)" />
    <Content Include="$(SolutionPackageZipFilePath)">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
  </ItemGroup>

  <Import Project="$(MSBuildToolsPath)\Microsoft.Common.targets" />
  <Import Project="$(PowerAppsTargetsPath)\Microsoft.PowerApps.VisualStudio.Solution.targets" Condition="Exists('$(PowerAppsTargetsPath)\Microsoft.PowerApps.VisualStudio.Solution.targets')" />

</Project>

Step 3. Remove all its content and simply replace it with the following:

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="AlbanianXrm.CDSProj.Sdk/1.0.5">
    <PropertyGroup>
        <SolutionPackageType Condition="'$(Configuration)' == 'Debug'">Unmanaged</SolutionPackageType>
        <SolutionPackageType Condition="'$(Configuration)' == 'Release'">Managed</SolutionPackageType>
        <SolutionFileVersion>$(FileVersion)</SolutionFileVersion>
    </PropertyGroup>
</Project>

And you're done.

The SolutionFileVersion node performs the magic of automatically managing the solution version based on the value passed via dotnet build /p:FileVersion=1.0.1.1. No manual edits required.

🕸️ And the web resources?

If the solution you are managing is the one that contains the web resources, add the mapping file:

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="AlbanianXrm.CDSProj.Sdk/1.0.5">
    <PropertyGroup>
        <SolutionPackageMapFilePath>$(MSBuildThisFileDirectory)map.build.xml</SolutionPackageMapFilePath>
        <SolutionPackageType Condition="'$(Configuration)' == 'Debug'">Unmanaged</SolutionPackageType>
        <SolutionPackageType Condition="'$(Configuration)' == 'Release'">Managed</SolutionPackageType>
    </PropertyGroup>
</Project>

Which, in my case, looks like this (nn is the publisher prefix):

<?xml version="1.0" encoding="utf-8"?>
<Mapping>
    <Folder map="WebResources\nn_" to="..\..\..\..\..\..\src\WebResources\nn_" />
</Mapping>

📦 Nice… but what about the `.nupkg` files?

Betim thought of that too. If you want to avoid the whole annoying process of:

Manually compiling plugin DLLs to generate .nupkg files.
Renaming them one by one into the name "expected" by the Dataverse solution.
Moving them one by one into the appropriate folder where dotnet build will look when rebuilding the solution (managed or unmanaged).

Just add an ItemGroup like the following to the project:

    <ItemGroup>
        <ProjectReference Include="..\..\src\Greg.Plugins\Greg.Plugins.csproj" />
    </ItemGroup>

Referencing the project created via pac plugin init, and that's it. The project itself, during build, will do the dirty work for you.

Below is a complete file example, where I also add a few extra parameters at my discretion:

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="AlbanianXrm.CDSProj.Sdk/1.0.5">
    <PropertyGroup>
        <SolutionPackageMapFilePath>$(MSBuildThisFileDirectory)map.build.xml</SolutionPackageMapFilePath>
        <SolutionPackageType Condition="'$(Configuration)' == 'Debug'">Unmanaged</SolutionPackageType>
        <SolutionPackageType Condition="'$(Configuration)' == 'Release'">Managed</SolutionPackageType>
        <SolutionFileVersion>$(FileVersion)</SolutionFileVersion>

        <!-- other properties added to manage logging and zip file generation -->
        <SolutionPackageEnableLocalization>true</SolutionPackageEnableLocalization>
        <SolutionPackageErrorLevel Condition="'$(Configuration)' == 'Debug'">Verbose</SolutionPackageErrorLevel>
        <SolutionPackageErrorLevel Condition="'$(Configuration)' == 'Release'">Info</SolutionPackageErrorLevel>
        <SolutionPackageZipFilePath Condition="'$(SolutionFileVersion)' != '' AND '$(Configuration)' == 'Debug'">$(OutputPath)$(MSBuildProjectName)_v$(SolutionFileVersion)_unmanaged.zip</SolutionPackageZipFilePath>
        <SolutionPackageZipFilePath Condition="'$(SolutionFileVersion)' != '' AND '$(Configuration)' == 'Release'">$(OutputPath)$(MSBuildProjectName)_v$(SolutionFileVersion)_managed.zip</SolutionPackageZipFilePath>
        <SolutionPackageZipFilePath Condition="'$(SolutionFileVersion)' == ''">$(OutputPath)$(MSBuildProjectName)_v$(SolutionFileVersion).zip</SolutionPackageZipFilePath>
    </PropertyGroup>

    <ItemGroup>
        <ProjectReference Include="..\..\src\Greg.Plugins\Greg.Plugins.csproj" />
    </ItemGroup>
</Project>

✅ Conclusions

In the end the problems that make us waste time in Model Driven projects are always the same: version numbers that communicate nothing, mapping breaking with Plugin Packages, manual rename of .nupkg files, uneven handling between PCF and Web Resources, PowerShell scripts patching Solution.xml. All repetitive work that adds no value and we'd rather forget.

The SDK template AlbanianXrm.CDSProj.Sdk does most of the heavy lifting: no scripts to force versioning, no manual copy/rename of packages, no “magical” builds different project by project. You reference the plugin project and it prepares the .nupkg as needed; you pass FileVersion and the solution aligns; you build and import. Done.

The Power Platform / Dynamics CRM community is, once again, that place where someone has already suffered before you and decided to share the cure. If today you are still manually renaming files or fixing version numbers at the end of the build, take a test solution, apply the template and measure how much time you save. After a few rounds it will be hard to go back.

A special thanks to Betim Beja for providing the AlbanianXrm.CDSProj.Sdk accelerator: it turned several recurring nuisances into details we simply no longer have to manage.

If you feel like it, let me know what you still miss to make your ALM truly “boring” (and therefore healthy): that is usually where it’s worth investing in the next improvement.

Forem: Riccardo Gregori

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...

💵 Dataverse Exchange Rates 101 💵

🔹 When Exchange Rate IS Applied

🔹 When Exchange Rate is NOT Applied

Generative Pages: The Right Hype, for the Wrong Reason

🦄 The Myth: “Finally, Custom UI in Model-Driven Apps!”

🔍 The Reality: Generative Pages Are a New Abstraction, Not a New Capability

🧪 WebResources vs PCFs: The Debugging and Testing Advantage

💾 Source Control and DevOps: Still a Win for WebResources

🌟 The Real Value Behind Generative Pages

🤔 Final Thoughts

Your Dataverse Solutions Deserve Better Builds (Here’s How)

🧱 Solutions

🔢 Source Versioning

🧩 And what about PCF?

🚀 Pipeline

🧮 Version Format

🔁 Back to the pipeline

🚨 Betim to the rescue 🚨

⁉️ How to use it

🕸️ And the web resources?

📦 Nice… but what about the .nupkg files?

✅ Conclusions

📦 Nice… but what about the `.nupkg` files?