Why Astro?

This section is focused on explaining the basics of Astro and what makes it great. Feel free to skip it; however, it gives useful context for future issues and frustrations.

Astro is a web framework for building content-driven websites like blogs (surprise, right?), marketing sites, and e-commerce sites. It is best-known for pioneering a new frontend architecture (the Island Architecture) to reduce JavaScript overhead and complexity compared to other frameworks. If you need a website that loads fast, is content-driven and has great SEO, then Astro is for you.

Another great feature of Astro is that it is UI-agnostic - bring React, Vue, Angular, htmx or anything in between.

Being content-driven and server-first does have limitations, meaning it isn't the right choice for highly complex client-side apps. However, it is ideal for knowledge-based websites, FAQ and similar portals, which makes it ideal for those Power Pages scenarios.

Creating a site

I decided to give it a try using official Microsoft Skills for Power Pages with Claude Code. I asked Claude to create a simple FAQ site with an About page using Astro.

The site was created quickly and ran well locally. (Btw, did you know that when you use official MS AI skills, you don’t actually create a site from scratch? Instead, the AI copies a provided sample from Microsoft and expands on it. This helps MS better control the shape of the initial site and makes validation easier.)

Next steps were deployment. And again, everything went well. The site was deployed and provisioned without any errors.

When I opened the site, the Home page was exactly as expected. However, as soon as I navigated to the About page, everything fell apart - the page was empty. URL was valid; there was no 404 Not Found error. The page was there - it just didn’t have any content.

Working Home Page

Empty About Page

I checked the page locally - it worked. However, the deployed site told a different story. So what went wrong?

Investigation

The first thing to check was the page record itself in Dataverse. Since the URL was valid, I checked if the page was provisioned. And it was indeed there. However, the Localized Content page was empty as well.

Next, I checked locally in the .powerpages-site folder - the generated folder where all the actual metadata lived. The webpage was generated there; however, the HTML was empty.

So PAC CLI correctly interpreted the page URL and created it, based on Astro folder structure (Astro uses file-based routing). However, instead of taking the actual HTML of the page, it left it empty.

After a deeper dive, I noticed something else - there were a few index.html as Web Files in the generated folder. That was odd - we shouldn’t have any. When I checked where those files belonged, I finally understood - each of them was under their respective pages: About and FAQ.

This meant that PAC CLI found those pages in the dist folder, understood that it needed to create a new page based on the folder; however, instead of treating the HTML inside the folder as the source for the page, it created it as a child Web File.

Technically, this means we can open both our About and FAQ pages as web files by going to their URLs directly.

Workaround (not really)

So, now that we know what PAC CLI did and why our pages are empty, can we do something about it?

Unfortunately, no.

We cannot force users to use web file URLs instead of actual pages. While it opens a file that looks like what we built, it runs outside the portal runtime - it won’t have any shared styles, header/footer wrappers or context objects (like signed-in user details) to make it actually functional. (see above)

Updating the Astro config to use direct files in the output instead of directories (ie generating about.html instead of about/index.html) doesn’t help either. PAC CLI just ignores them.

The only “option” is to treat the Astro project as a pure SPA - ie writing a custom router definition and combining everything into one HTML file. That way PAC CLI will pick it up, and we can resolve routes with a bit of JS.

However, this isn't a real solution. If you do this, the Home page will grow insanely large very quickly as all page content is literally crammed into the initial load. It completely defeats the purpose of using Astro, and it creates a nightmare for accessibility standards.

Deploying directly from sample

Ok, I thought to myself, maybe AI messed up somehow. Let’s start from the source directly.

I copied the Microsoft sample directly (which contains, beyond the Home page, the About page as well), then manually ran the PAC CLI command to upload the code site.

And guess what? Results were exactly the same - the About page was generated as a separate page without any HTML inside, and the actual page was just added to the Web Files.

Conclusion

I just cannot recommend using Astro with Power Pages as it is right now.

Honestly, I don’t know if this is some issue with the recent PAC CLI updates or if Microsoft genuinely missed this one, but Astro just doesn’t work out of the box.

Power Pages Code Sites were always targeting pure SPAs first (React, Angular, Vue). Having only one route page and loading everything else as additional JS files works really well for that architecture.

Astro is different. It is a multi-page setup first. Ironically, this MPA approach would align perfectly with how traditional Power Pages actually work under the hood, making it a great solution for content-driven scenarios like FAQs and knowledge bases.

Unfortunately, until PAC CLI understands how to handle multi-page output, I cannot recommend Astro. I really hope Microsoft addresses this soon.

Credits

Cover image by PixaBay

Now, we finally have an easy way to automate our admin tasks - with the latest PAC CLI 2.12.X update, all those Admin APIs are exposed as dedicated commands.

My only pet peeve with this release is the command name pac power-pages, which is confusing since we already have pac pages to work with site content and ALM. Furthermore, power-pages on its own doesn’t articulate that these are admin commands. Since these commands are currently in preview, I really hope that MS will reconsider the naming convention before GA.

Important

As of writing this article, pac power-pages commands are in Preview.

With this release, Microsoft introduced 40 new commands under pac power-pages. For the whole list of commands, see the official documentation.

In this article, we will review the ones I find the most interesting and how they fit into real-world admin scenarios.

Automated Certificate Management

One of the most annoying tasks in Power Pages is managing custom SSL certificates. As standard security practice dictates, these certificates need to be rotated often, based on your company's security policy. The typical process was as follows: set up a calendar reminder for when the certificate is about to expire, obtain the new one and manually upload the certificate through the UI. I kid you not - I still have meeting invites in my calendar from some of my previous clients specifically to update their certificates.

Finally, all of this can become a thing of the past with the introduction of 2 new commands:

• pac power-pages upload-certificate - allows you to upload a certificate for the specified website
• pac power-pages add-ssl-binding-by-portal - allows you to bind a certificate to the specified site

Now, instead of doing everything manually, you can set up a fully automated workflow, for example, using Azure Key Vault automated renewals paired with a deployment pipeline. When a certificate is renewed, an automated pipeline can get the new certificate as a .pfx file, upload it, and bind it using PAC CLI.

And no more “renewal” meetings in your calendar or calls about an “unsecure” website.

Site Lifecycle Controls

How often, after deploying changes to your website, do you need to go to the admin center to manually hit that sweet “Restart Website” button to fully “nuke” server-side cache and allow your changes to take effect? And how many times have you wished to have a short command to do it or even make it part of the deployment?

Well, now your wish has been granted- the new pac power-pages restart-website command can do just that - hard restart your website.

In addition, two new commands, start-website and stop-website, can help you manage your site state much more easily. However, be careful - stop-website will actually stop your website completely, instead of putting it into maintenance mode. This means that your users will be greeted by generic 503 or error pages, so make sure you are using this command intentionally.

This is actually my only grievance with this command group, as having a simple command to put the website into maintenance mode would be an ideal addition for the proper ALM pipeline.

Exception Governance

Power Pages as a platform constantly evolves, and Microsoft is constantly introducing new changes. This also means that some functionality is being deprecated (either by being legacy/outdated or because of security implications). The most recent example of this is Web API wildcard deprecation. This setting led to the recent data leaks and hacker attacks. Starting last week (September 14, 2026), your website can no longer use wildcards as a Web API option, making it much more secure.

However, not all of the deprecations are equal. Sometimes, your company needs more time to adjust its website. Or legacy code is just too complex and process-dependent, and the deprecation timeline just isn’t feasible. What should you do in that case?

Well, that's where the exception functionality comes into play.

Exception functionality allows you to grant a break-glass admin exception for a specific exception type for a specific website. Admins need to explicitly acknowledge the risk of granting the exception.

Microsoft provides the following commands to manage exceptions:

• pac power-pages get-affected-sites - get the list of sites that are affected by a specific exception type
• pac power-pages get-exceptions - get the list of exceptions applied at the tenant level
• pac power-pages grant-exception - grants an exception for a specific exception type to a specific site
• pac power-pages revoke-exception - revokes a previously granted exception

Currently, the only exception supported is “WebApiStarRetirement”, which is directly related to the recent wildcard deprecation. However, I would definitely not recommend granting an exception for this one if you can avoid it - it is indeed too permissive, and you should definitely limit its scope.

In the future, when new deprecations arrive, using the commands above will allow you to better prepare and remediate deprecations without full-blown production downtime.

Conclusion

The introduction of the pac power-pages commands is a massive step forward for Power Pages administration. No longer do we need to rely on manual steps or complex REST API calls. Having a unified set of commands that are easily scriptable opens the door for a much more maintainable and structured DevOps and management story. I still hope that MS will adjust the name to something more appropriate before GA to avoid confusing users, but having these capabilities natively in the CLI is a major milestone for Power Pages governance.

Credits

Image by Dimitrios K from Pixabay

A couple of years ago, a new option emerged - Cloud Flows with a native Power Pages trigger. While a massive step forward, it wasn't always the right fit for high-performance, synchronous tasks.

Now, with the full GA of Server Logic and the recent addition of agentic skills to automate its creation, the question arises: where should your Power Pages backend live?

Let's start by understanding what each option brings to the table.

Companion App

The Companion App approach emerged almost immediately with the introduction of Dynamics Portals (yep, it's that old). It refers to any external service built to act as a dedicated backend for your site. Usually built with Azure Functions or Azure Web Apps to simplify the Dataverse connection, this approach was the only way to handle complex scenarios for a decade.

However, it suffers from two primary issues:

• Security: You had to build custom middleware to handle requests. While the OAuth 2.0 implicit grant flow became a de facto default, it required significant "handshake" code on both the client and the server (even with Microsoft providing code samples to simplify it).
• Maintainability: Your code lives in a completely separate ecosystem. You need separate Git repositories and deployment pipelines, which can lead to a "split-brain" architecture where the frontend and backend can easily fall out of sync.

Cloud Flows

The introduction of native Power Pages support in Power Automate Cloud Flows, with dedicated trigger and response actions, was a huge win several years ago. It immediately made the Power Pages sites much more powerful by allowing the usage of 1000 built-in connectors, without the need to manage complex authentication or exposing any secrets. This makes it ideal for sending messages in Teams or emails via Outlook, or performing any action with the existing connector for external systems.

A cherry on top was native support for the Web Roles, which ensured that users had the correct role before calling the flow. However, Cloud Flow doesn't run in the user's context, meaning it doesn't apply Table Permissions in any capacity. It also doesn't know which Contact triggered the execution, unless you pass the id parameter explicitly and then perform additional validations inside the flow.

Unfortunately, despite all the benefits, Cloud Flow were not ideal for synchronous, high-performance operations.

Server Logic

Server Logic is the latest addition to the Power Pages and, in my opinion, one of the most important. Although long overdue, it finally gives developers a “native” backend to work with.

It allows you to write JavaScript (ECMAScript 2023 compliant) that runs directly on the Power Pages server. However, it is important to understand the boundaries: this is a sandboxed server environment. You cannot use browser-specific APIs (like window or document), and standard client-side networking tools like fetch or XMLHttpRequest are replaced by the native Connector.HttpClient object. Additionally, for security reasons, you cannot currently import external npm packages or libraries.

Unlike Cloud Flows, which are asynchronous and better suited for "workflow" tasks, Server Logic is designed for synchronous, high-performance operations. It is ideal for:

• Calling a service like Stripe or OpenAI without exposing your API keys to the browser.
• Running multi-table logic before allowing a Dataverse write.
• Performing secure server-side filtering or returning aggregated data structures.

Security Context

By design, Server Logic runs in the context of the current user, with all table permissions applied. In 90% of scenarios, this is exactly what we need - it ensures that your backend logic respects the existing security hierarchy. You don't have to manually re-validate if a user "should" see a record; the platform does it for you.

However, this "User Context" can be a double-edged sword. If you need to perform a "System Context" operation, for example, validating a promo code against a "Marketing Campaigns" table that is hidden from regular users, Server Logic will return nothing because it respects the user's lack of permissions.

Fingers crossed that Microsoft will update this in the future and allow us to perform System-level queries natively, empowering an already capable option.

Agentic development workflow

The recent release of the Power Pages Agentic Skills for Claude Code and GitHub Copilot has turned the complex task of backend configuration and creation into a more streamlined and straightforward process.

Important

Compatibility Note: These agentic skills are specifically designed for the newest SPA-based website creation and management workflows. They will not function properly with traditional Power Pages sites.

Here is how these skills reshape the build process:

• /add-server-logic: generates a Server Logic endpoint, including not just the code, but also the endpoint configuration, security role assignment, etc.
• /add-cloud-flow: acts as the bridge to your automated workflows. It identifies an existing Power Pages-enabled Cloud Flow and generates the necessary code to invoke it and process its response.
  • IMPORTANT This skill does not create a new Cloud Flow. You still need to design your business logic within the Power Automate designer first; the agent just handles connecting it to your SPA.
• /integrate-backend: this is the most interesting one. Acting as a Power Pages Architect, the agent analyzes your project's requirements and determines the optimal approach for each feature - whether that's a simple Web API call, a synchronous Server Logic endpoint, or an asynchronous Cloud Flow. It then orchestrates the entire build sequence across your project files.

How to choose

My advice is to follow a "Native-First" approach: only use external services when the platform's sandbox limits your requirements.

Start with Server Logic for almost everything. If your task involves securing an API key, performing a synchronous calculation, or validating data before it hits Dataverse, Server Logic is your best friend. It offers the lowest latency and tightest integration.

Switch to Cloud Flows when the ecosystem is the priority. If your requirement ends with an action in another service, like sending an approval email via Outlook, posting a notification to a Teams channel, or updating a file in SharePoint, don't reinvent the wheel. Use the native Power Pages trigger to invoke a flow and let prebuilt connectors do the work.

Reserve the Companion App for the "heavy tasks". If you find yourself hitting the limits of the JavaScript sandbox and task is too complex or code-depndant for Flow, this is a choice for you. Use an Azure Function or Web App if you need to:

• Use a proprietary C# library or a specific NuGet/NPM package.
• Perform high-intensity compute tasks (like image/video processing).
• Access on-premises data via VNet integration.

Remember that you don't have to choose just one. You might use Server Logic to validate a form synchronously, a Cloud Flow to notify the team afterward, and a Companion App to generate a complex PDF report in the background; all inside the same site.

The goal isn't to find the "perfect" tool for the whole project, but to choose the most efficient tool for the specific task at hand.

Conclusion

In my opinion, Server Logic is the new default for the Power Pages backend. It offers a great combination of capabilities to create secure and high-performance endpoints, internal implementations of which shouldn't be exposed to the client.

This doesn't mean that Cloud Flows or Companion Apps are obsolete. They still serve a purpose by solving specific problems and being ideal for their own scenarios.

You don't have to choose one - just select the tool that is the best for the job.

Credits

Cover Image by Willi Heidelbach from Pixabay

Server Logic Image by Microsoft

My blog has been running on Jekyll and GitHub Pages since 2019. When I first started writing, I didn't just want a place to share ideas; I wanted a playground where I could experiment.

Back in 2019, Dynamics Portals (way before they became Power Pages) were gradually becoming my main focus. I decided to go with Jekyll as I wanted a blog-focused ecosystem that ran on Liquid, since I wanted to sharpen my skills with it. The main idea was that building my personal website from scratch would help me to upgrade my web development knowledge.

However, now things are different. Power Pages is evolving as a platform, allowing for hosting SPA and being a much more development-focused environment. Meanwhile, Liquid isn't part of this transformation. And to be honest, there aren't many things that I haven't tried with Liquid for the last 7 years.

While Jekyll remains a fantastic, reliable choice for static sites, I realized that to keep improving my craft, it was time to try something new.

Why Astro?

I first found Astro two years ago, when I was creating a documentation website for my Lookup To Select project. Although I could have built it with Jekyll, I wanted to try something new.

After some searching and comparison, Astro was looking like an ideal candidate:

• support for MD and MDX out of the box,
• static output, so I can still use it with GitHub Pages,
• a wide variety of existing templates,
• framework flexibility, allowing me to use any frontend library or stay HTML-first,
• native support for TypeScript and modern JavaScript features,
• a growing community of passionate developers.

Overall, Astro felt like the perfect upgrade, offering a modern development experience while still allowing me to maintain the static site benefits I loved about Jekyll.

Creating a new website felt great, and even back then, I was thinking of moving from Jekyll to Astro. However, there was no “one-click” solution - my existing posts contained a lot of custom liquid code that would require significant refactoring. I tried to use AI for the job - it seemed like an ideal approach; however, technology wasn't there yet, and the initial migration attempt failed. So I decided to postpone the idea.

Now, with Astro just releasing version 6 and Power Pages supporting Astro out of the box, I decided that the time is right and I should try again.

Migration

To move to Astro, I needed to:

• rebuilt all the liquid templates and custom components as Astro components,
• migrate all of my posts,
• maintain consistent styling and branding,
• preserve all existing URLs and RSS feeds,
• ensure that the search and subscribe functionality still works.

I decided to go with Bun as the package manager. I know that it is technically not 100% supported, but I was using Bun a lot recently and really like how snappy and all-in-one it is.

From Liquid to .astro Components

The primary task was to replace my liquid templates with pure .astro components. In the future, I might add some React or other frameworks, but for the start, pure HTML inside Astro components felt like the best option.

While Jekyll uses a "top-down" approach where a layout wraps around content, Astro treats everything as a component - even the pages themselves.

Understanding Astro's Routing & Page Handling

If you're coming from Jekyll, the biggest mental shift is how Astro handles the pages/ directory.

• File-Based Routing: In Jekyll, your structure is often dictated by _posts and permalinks in frontmatter. In Astro, any file inside src/pages/ automatically becomes a route.

• The .astro File Structure: Unlike Liquid, which intersperses logic and HTML, an Astro component uses a "Code Fence" (the --- block) to handle all your logic at build time.

For my migration, I utilized Dynamic Routes to handle my legacy post structure. Instead of having hundreds of individual files in my pages folder, I used a single [...slug].astro file that fetches content from my collections and generates the pages dynamically at build time.

Managing Content with Collections

In Jekyll, your posts are just files in a directory. There's no built-in way to enforce that every post has a title or a date, and if you make a typo in the frontmatter, the build might just fail silently. Astro's Content Collections API solves this by treating your Markdown files like a database with a schema.

By defining a schema using Zod in content.config.ts, I was able to:

• Enforce Data Integrity: I made fields like title and date required. Beyond just checking for missing fields, Astro validates the provided data types, for example: ensuring that dates are actual Date objects and tags are arrays of strings. If a legacy post had a malformed date or an incorrect data type, Astro caught it at build time before it could break the site.

• Enable Type Safety: My IDE now provides autocomplete for post properties, so I don't have to remember if a field was named thumbnail or image.

My post collection schema looks like this (note the use of .optional() to define optional fields and types like z.coerce.date() to ensure that date strings are properly parsed into Date objects):

const posts = defineCollection({
  loader: glob({ pattern: '**/*.{md,mdx}', base: './src/content/posts' }),
  schema: z.object({
    layout: z.string().optional(),
    title: z.string(),
    date: z.coerce.date(),
    description: z.string().optional().default(''),
    excerpt: z.string().optional().default(''),
    shortDescription: z.string().optional().default(''),
    img: z.string().optional().default(''),
    image: z.string().optional().default(''),
    tags: z.array(z.string()).optional().default([]),
  }),
});

Below is an example of a frontmatter error that Astro would catch during the build process, which would have been much harder to debug in Jekyll.

Project Structure Mapping

To make the transition smoother, I used the GitHub Copilot CLI with Opus 4.6 to create a migration plan, then used Sonnet 4.6 to execute it.

Here is how my Jekyll structure maps over to Astro:

• _layouts → src/layouts (directly mapped, with some adjustments to fit Astro's component model)
• _includes/ → src/components/ (with additional customization specific components, like Video and UpdateBlock living inside the mdx folder)
• _data → src/data (with not just a list of projects, but an additional feeds configuration for RSS, more about it later)
• assets → public/assets (structure updated to match the typical Astro structure)
• _pages → src/pages
• _posts → src/content/posts

AI performed significantly better than it did two years ago, aligning the projects with much higher accuracy.

Content Migration

Honestly, this part was scaring me the most, as there would be a lot of manual work with different liquid-specific tags, but AI was able to resolve it pretty quickly (by writing some temporary Python scripts for replacement and update logic).

One specific challenge was URL preservation. Jekyll uses a _posts/YYYY-MM-DD-title.md naming convention but omits the date in the final URL. Since Astro uses file paths for slugs by default, I updated the getStaticPaths function inside [...slug].astro component to strip the date prefix, ensuring my legacy links didn't break.

export const getStaticPaths: GetStaticPaths = async () => {
  const posts = await getCollection('posts');
  return posts.map((post) => ({
    params: { slug: post.id.replace(/\.mdx?$/, '').replace(/^\d{4}-\d{2}-\d{2}-/, '') },
    props: { post },
  }));
};

Other key adjustments included:

• Frontmatter: Updated the schema in content.config.ts for strict type safety.
• Liquid Tags: Replaced {% highlight %} with fenced code blocks and {% include %} with MDX component imports. All .md files were renamed to .mdx to support these components. All of these changes were done via AI.

Styling and RSS

I refactored my SCSS to follow a "one partial per component" structure, switching from the older @import syntax to the modern @use rule.

For RSS, Astro's default package produces RSS 2.0, but I wanted Atom format. I used the following article as a reference and built a custom RSS generation pipeline inside feeds.ts using feed and unify packages.

I also took the opportunity to refresh the site's look and feel a bit. This included a new hero post layout to make the latest updates pop, plus a much simpler header. I purposely kept the same general feel for this first pass, but I plan to experiment with it more in the future.

New Features

The migration allowed me to implement several upgrades:

• Pagefind Search: I replaced my jQuery-based search with Pagefind. It runs post-build to generate a static index, resulting in blazing-fast, low-bandwidth searches.
• View Transitions: This gives the site an SPA-like feel with smooth animations between pages. Currently, it keeps the header persistent during navigation, and I plan to experiment with more dynamic transitions soon.
• Font Optimization: I'm using Astro's new Font API to handle web font optimization automatically.

View Transition demo is available below, and you can also check it out live on the site by clicking around the posts (notice that the header stays persistent while the content transitions in and out).

Verdict

I'm thrilled with this upgrade. The site feels modern, fast, and most importantly, it is once again a playground for me to experiment. AI helped me a lot this time around, making the daunting task of refactoring years of Liquid code manageable.

Credits

Cover image by NASA-Imagery from Pixabay

Available styling

First, let’s discuss the prerequisites: you have a Power Pages site on the Enhanced Data Model with a Copilot agent provisioned. We will be customizing the “modern” agent, so if you still have Power Virtual Agent, this guide will not apply.

We will be using this official Microsoft article as a reference point. Spoilers - MS needs to update it, cause some things just don’t work as expected.

To make the standard Copilot agent look better, we want to update the following elements:

• replace the widget icon with something more Christmas-themed
• update the Header of the chat interface with festive colors
• update chat bubbles for the user and Copilot with holiday colors

New icon

According to an article on MS Learn, we need to run the following JS code to replace the icon.

<script>
document.addEventListener('DOMContentLoaded', function() {
   var buttons = document.getElementsByClassName("pva-embedded-web-chat-widget");
    buttons[0].innerHTML = '<img src="<image URL>" height= "70px" width = "70px" />';
}, false);
</script>

The problem with this code is that it should trigger when the initial DOM tree is loaded. However, a “modern” agent is added via - dromroll please - React, so the actual render will occur after the DOM tree finishes loading, and this code won’t work.

Instead, we should use MutationObserver. The MutationObserver interface provides the ability to watch for changes being made to the DOM tree. If you never worked with Mutation Observer before, it is pretty simple - you create an observer object that will watch the target element and call the provided callback function when the changes occur. Those changes can be an addition of a new child element to the DOM tree, an attribute change, such as classes update, etc. Inside the callback function, we can validate what the change is and react accordingly.

We can add the observer to the document body itself; however, there are multiple changes constantly happening to the document body, which will lead to multiple triggers of the callback function, that will be completely unrelated to what we need. So ideally, we want the observer to be as close to the part that we need. To do so, we need to understand what actually renders our agent.

Microsoft has a web template called Power Virtual Agents. This template is automatically injected at the end of the page. After reviewing this template, we can see that the element that will be there from the start is the div with the name webChat.

So let’s attach the observer to the “webChat” div element and wait until the div with the class “pva-embedded-web-chat” is rendered. Since it is rendered with our button as a subchild, this is exactly what we need.

const targetClass = 'pva-embedded-web-chat';

// Select the node that will be observed for mutations (e.g., the body)
const targetNode = document.getElementsByName("webChat")[0];

// Options for the observer: watch for child additions/removals and descendent changes
const config = {
    childList: true,
    subtree: true // Monitor all descendants
};

// Callback function to execute when mutations are observed
const callback = (mutationList, observer) => {
    for (const mutation of mutationList) {
        // Check if the mutation type is 'childList' (nodes added or removed)
        if (mutation.type === 'childList') {
            // Iterate over the added nodes
            for (const node of mutation.addedNodes) {
                // Check if the added node is an Element and has the target class
                if (node.nodeType === Node.ELEMENT_NODE && node.classList.contains(targetClass)) {
                    let button = document.querySelector(".pva-embedded-web-chat-widget > button");
                    // <a href="https://www.flaticon.com/free-icons/chat" title="chat icons">Chat icons created by Marz Gallery - Flaticon</a>
                    button.innerHTML = '<img src="/christmas-chatbot-icon.png" height="48px" width="48px" />';
                    // Stop observing once the element is found
                    observer.disconnect();
                }
            }
        }
    }
};

// Create a new MutationObserver instance with the callback function
const observer = new MutationObserver(callback);

// Start observing the target node for the configured mutations
observer.observe(targetNode, config);

Let’s apply the code, add some styling to make the widget a bit bigger, and see what we got.

Looks nice during the first load. However, as soon as we open the chat window and then close it again, we are back to square one (except for some styling changes). Why is that? Well, the answer is still React. It dynamically rerenders parts that are needed and removes our chat button with the changes. So what should we do to prevent it? The simplest way is to use the second observer.

We will add the second observer to the “pva-embedded-web-chat” div, as it stays the same between rerenders. Now we will wait until the div with the class “pva-embedded-web-chat-widget” is rendered. And we will re-add our image then.

function initialRenderObservation() {
    const targetClass = 'pva-embedded-web-chat';

    // Select the node that will be observed for mutations (e.g., the body)
    const targetNode = document.getElementsByName("webChat")[0];

    // Options for the observer: watch for child additions/removals and descendent changes
    const config = {
        childList: true,
        subtree: true // Monitor all descendants
    };

    // Callback function to execute when mutations are observed
    const callback = (mutationList, observer) => {
        for (const mutation of mutationList) {
            // Check if the mutation type is 'childList' (nodes added or removed)
            if (mutation.type === 'childList') {
                // Iterate over the added nodes
                for (const node of mutation.addedNodes) {
                    // Check if the added node is an Element and has the target class
                    if (node.nodeType === Node.ELEMENT_NODE && node.classList.contains(targetClass)) {
                        let button = document.querySelector(".pva-embedded-web-chat-widget > button");
                        // <a href="https://www.flaticon.com/free-icons/chat" title="chat icons">Chat icons created by Marz Gallery - Flaticon</a>
                        button.innerHTML = '<img src="/christmas-chatbot-icon.png" height="48px" width="48px" />';
                        // Stop observing once the element is found
                        observer.disconnect();
                        // Adding second observer
                        followUpRenderObservation();
                    }
                }
            }
        }
    };

    // Create a new MutationObserver instance with the callback function
    const observer = new MutationObserver(callback);

    // Start observing the target node for the configured mutations
    observer.observe(targetNode, config);
}

function followUpRenderObservation() {
    const targetClass = 'pva-embedded-web-chat-widget';

    // Select the node that will be observed for mutations (e.g., the body)
    const targetNode = document.getElementsByClassName("pva-embedded-web-chat")[0];

    // Options for the observer: watch for child additions/removals and descendent changes
    const config = {
        childList: true,
        subtree: true // Monitor all descendants
    };

    // Callback function to execute when mutations are observed
    const callback = (mutationList, observer) => {
        for (const mutation of mutationList) {
            // Check if the mutation type is 'childList' (nodes added or removed)
            if (mutation.type === 'childList') {
                // Iterate over the added nodes
                for (const node of mutation.addedNodes) {
                    // Check if the added node is an Element and has the target class
                    if (node.nodeType === Node.ELEMENT_NODE && node.classList.contains(targetClass)) {
                        let button = document.querySelector(".pva-embedded-web-chat-widget > button");
                        // <a href="https://www.flaticon.com/free-icons/chat" title="chat icons">Chat icons created by Marz Gallery - Flaticon</a>
                        button.innerHTML = '<img src="/christmas-chatbot-icon.png" height="48px" width="48px" />';
                    }
                }
            }
        }
    };

    // Create a new MutationObserver instance with the callback function
    const observer = new MutationObserver(callback);

    // Start observing the target node for the configured mutations
    observer.observe(targetNode, config);
}

$(document).ready(function () {
    initialRenderObservation();
});

Let’s apply the updated code and see what we get.

Much better now - exactly what we wanted.

Header customization

Next, we want to update the header - both background and text color. This is actually the same as in the documentation - just update the proper CSS class.

As for the colors, we will go with the classic Christmas combo of Red background and Gold text.

/* open chat header */
.pages-chatbot-header {
    background: #b11c2c;
    color: #ffe05c;
}

Looks great - moving to the final step now.

Chat bubble customization

To make chat bubble feel more festive, we will update Copilot responses to be Green with White text, and user responses to be Red with White text.

For the background we need to modify CSS a bit, comparing to what is specified in the docs - the background needs to be applied one level deeper to the “webchat__text-content” class.

The text styling works as documented.

/* Copilot text bubble */
.webchat__bubble:not(.webchat__bubble--from-user) .webchat__bubble__content,
.webchat__bubble:not(.webchat__bubble--from-user) .webchat__bubble__content .webchat__text-content {
    background-color: #075600 !important;
    border-radius: 5px !important;
}

.webchat__bubble:not(.webchat__bubble--from-user) p {
    font-weight: 400;
    color: #ffffff;
}

/* User text bubble */
.webchat__bubble.webchat__bubble--from-user .webchat__bubble__content,
.webchat__bubble.webchat__bubble--from-user .webchat__bubble__content .webchat__text-content {
    background-color: #b11c2c !important;
    border-radius: 5px !important;
}

.webchat__bubble.webchat__bubble--from-user p {
    font-weight: 400;
    color: #ffffff;
}

And the final result looks great!

Final code can be found below:

<style>
    /* Widget */
    .pva-embedded-web-chat-widget {
        background-color: #208b3a;
        border: 1px solid #000000;
        width: 60px !important;
        max-width: 60px !important;
        height: 60px !important;
    }

    /* open chat header */
    .pages-chatbot-header {
        background: #b11c2c;
        color: #ffe05c;
    }

    /* Copilot text bubble */
    .webchat__bubble:not(.webchat__bubble--from-user) .webchat__bubble__content,
    .webchat__bubble:not(.webchat__bubble--from-user) .webchat__bubble__content .webchat__text-content {
        background-color: #075600 !important;
        border-radius: 5px !important;
    }

    .webchat__bubble:not(.webchat__bubble--from-user) p {
        font-weight: 400;
        color: #ffffff;
    }

    /* User text bubble */
    .webchat__bubble.webchat__bubble--from-user .webchat__bubble__content,
    .webchat__bubble.webchat__bubble--from-user .webchat__bubble__content .webchat__text-content {
        background-color: #b11c2c !important;
        border-radius: 5px !important;
    }

    .webchat__bubble.webchat__bubble--from-user p {
        font-weight: 400;
        color: #ffffff;
    }
</style>

<script>
    function initialRenderObservation() {
        const targetClass = 'pva-embedded-web-chat';

        // Select the node that will be observed for mutations (e.g., the body)
        const targetNode = document.getElementsByName("webChat")[0];

        // Options for the observer: watch for child additions/removals and descendent changes
        const config = {
            childList: true,
            subtree: true // Monitor all descendants
        };

        // Callback function to execute when mutations are observed
        const callback = (mutationList, observer) => {
            for (const mutation of mutationList) {
                // Check if the mutation type is 'childList' (nodes added or removed)
                if (mutation.type === 'childList') {
                    // Iterate over the added nodes
                    for (const node of mutation.addedNodes) {
                        // Check if the added node is an Element and has the target class
                        if (node.nodeType === Node.ELEMENT_NODE && node.classList.contains(targetClass)) {
                            let button = document.querySelector(".pva-embedded-web-chat-widget > button");
                            // <a href="https://www.flaticon.com/free-icons/chat" title="chat icons">Chat icons created by Marz Gallery - Flaticon</a>
                            button.innerHTML = '<img src="/christmas-chatbot-icon.png" height="48px" width="48px" />';
                            // Stop observing once the element is found
                            observer.disconnect();

                            followUpRenderObservation();
                        }
                    }
                }
            }
        };

        // Create a new MutationObserver instance with the callback function
        const observer = new MutationObserver(callback);

        // Start observing the target node for the configured mutations
        observer.observe(targetNode, config);
    }

    function followUpRenderObservation() {
        const targetClass = 'pva-embedded-web-chat-widget';

        // Select the node that will be observed for mutations (e.g., the body)
        const targetNode = document.getElementsByClassName("pva-embedded-web-chat")[0];

        // Options for the observer: watch for child additions/removals and descendent changes
        const config = {
            childList: true,
            subtree: true // Monitor all descendants
        };

        // Callback function to execute when mutations are observed
        const callback = (mutationList, observer) => {
            for (const mutation of mutationList) {
                // Check if the mutation type is 'childList' (nodes added or removed)
                if (mutation.type === 'childList') {
                    // Iterate over the added nodes
                    for (const node of mutation.addedNodes) {
                        // Check if the added node is an Element and has the target class
                        if (node.nodeType === Node.ELEMENT_NODE && node.classList.contains(targetClass)) {
                            let button = document.querySelector(".pva-embedded-web-chat-widget > button");
                            // <a href="https://www.flaticon.com/free-icons/chat" title="chat icons">Chat icons created by Marz Gallery - Flaticon</a>
                            button.innerHTML = '<img src="/christmas-chatbot-icon.png" height="48px" width="48px" />';
                        }
                    }
                }
            }
        };

        // Create a new MutationObserver instance with the callback function
        const observer = new MutationObserver(callback);

        // Start observing the target node for the configured mutations
        observer.observe(targetNode, config);
    }

    $(document).ready(function () {
        initialRenderObservation();
    });
</script>

Conclusion

In this article, I provided step-by-step instructions on how you can customize your Copilot agent in Power Pages, focusing on making it Christmas-themed. Hope you enjoyed this article.

Credits

Cover Image by Shawn Suttle from Pixabay

What is htmx?

htmx is a JavaScript library that lets you write less JS by extending HTML (hence the name HTMX). htmx allows you to extend HTML so that components can react to events, send HTTP requests, perform CSS transitions, and much more. You can find more about htmx by visiting htmx official website.

The simplest example of htmx will look like this.

  <button hx-post="/clicked" hx-swap="outerHTML">
    Click Me
  </button>

The hx-post and hx-swap attributes on this button tell htmx:

“When a user clicks on this button, issue an AJAX request to /clicked, and replace the entire button with the HTML response.”

Liquid and htmx

Liquid is a template language. This means that it is executed on the server. Because of this, any interactivity with liquid usually requires a full-page refresh. Which, in the modern web landscape, can feel outdated and slow for the users.

This is where htmx comes to play - we can use it to simplify getting Liquid from the server and making our pages much more dynamic.

Using Liquid with dynamic fetching is not a new idea. Way before we had Power Pages Web API, the most common way to get the data was to use a page as an API approach - a web template behind the page was using fetchxml to perform necessary queries, and print a formatted response as part of the page.

With htmx, we will use the same approach - create a new page to serve as an API. However, what makes this different from the usual way is twofold: htmx will make it easier to query and consume the page, and the page itself will return valid HTML instead of pseudo-JSON. Although we could achieve the same results while using JS, htmx allows us to write less code, keeping logic on the page cleaner and more understandable.

Active Search

Imagine we have the following requirement: show the list of available courses and allow the user to search by the course name. The search should happen without a full page refresh.

Usually, we wouldn’t go with the Liquid and fetchxml - since we don’t want to have the full page refresh. However, using Power Pages Web API can require a lot of JS code and additional site setting configuration. And what if we need to have an additional hidden filtering condition (like only show a certain type of courses) that should not be visible to the user? You can, of course, use the new Server Logic; however, it is still in Preview, and we also want to keep our code simple. So let’s use htmx and Liquid to fulfill the requirement.

First, we need to understand how our page will work and which components we will need.

We would need the following components:

• an input that allows users to search for courses
• the list of courses
• a loading indicator to show to the users while we are searching

We can use htmx with the search input to both load the initial list and trigger a reload when the user inputs the search term.

    <input class="form-control" 
       type="search"
       name="search" 
       placeholder="Begin Typing To Search Courses..."
       hx-get="/search-courses"
       hx-trigger="input changed delay:500ms, keyup[key=='Enter'], load"
       hx-target="#search-results"
       hx-indicator=".htmx-indicator">

The hx-get tells htmx to perform the GET request to the /search-courses URL. It will automatically include the value of our input as the “search” query parameter (because we defined the name of our control as “search”).

The hx-trigger attribute tells htmx to trigger on the input with a 500ms delay, to ensure we don’t trigger events on every key press. We pass the “changed” modifier to ensure that only when the value has actually changed, to perform a request. We added two additional comma-separated triggers: when users click Enter and on the initial page load.

The hx-target attribute tells htmx to swap the content of the element with the id “search-results” with the content of the response.

The hx-indicator attribute tells htmx that we are using an element with the class “htmx-indicator” as a loading indicator, so htmx will show it while waiting on the response, and will hide it as soon as the response is received.

Now let’s add a simple svg and “Searching...” text as a loading indicator.

  <div class="htmx-indicator d-flex align-items-center" id="htmx_search_indicator">
    <div style="width: 100px;">
      <!-- SVG goes here -->
    </div>
    <span style="font-size: 24px;">Searching...</span>
  </div>

Next, we will add the “search-results” element, where the list will be rendered. We will use the “dl” HTML - description list element.

<dl id="search-results"></dl>

Last, but certainly not least, we need to implement the /search-courses URL. For that, we will create a new web page that will use fetchxml to get the list of courses and then will render “dt” and “dd” tags for each course, with the corresponding course name and description. It will also use the provided “search” query parameter as the criteria. In case we have no results, we will simply return div with “No Results Found” text.

{% fetchxml courses %}
<fetch mapping='logical'>
  <entity name='cr770_course'>
    <attribute name='cr770_courseid'></attribute>
    <attribute name='cr770_coursename'></attribute>
    <attribute name='cr770_description'></attribute>
    <order attribute='cr770_coursename'></order>
    <filter type='and'>
      <condition attribute='cr770_coursename' operator='like' value='%{{params.search}}%'></condition>
    </filter>
  </entity>
</fetch>
{% endfetchxml %}

{% if courses.results.entities.size > 0 %}
  {% for course in courses.results.entities %}
  <dt>{{course.cr770_coursename}}</dt>
  <dd>{{course.cr770_description}}</dd> 
  {% endfor %}
{% else %}
<div>No Results Found</div>
{% endif %}

Combining all of this (and a bit of CSS to style our list), we are getting the dynamic and interactive UI that we needed in just 50 lines of HTML with no extra JS code.

Infinite Scroll

But what if we have too much data to load all at once? One of the modern ways to solve an issue like that is to implement an Infinite Scroll mechanism. It will work as follows: first, we will load a small subset of data, say 10 records. Then, as soon as we scroll to the last record, we will load the next set of 10 records. Repeat until all the data is loaded.

To make this happen, we need to adjust both our main page, the Liquid page, and the triggering logic for additional data load.

On the main page, we need to add a new loader indicator - specifically for when we load additional data. We will place it below the “search-results” container, so it will always show at the bottom, where the new results will render. We also need to update the hx-indicator attribute on the search input to point to the id of the search indicator instead of the "htmx-indicator" class, which will exist on the new indicator as well.

Input with updated hx-indicator

    <input class="form-control" 
       type="search"
       name="search" 
       placeholder="Begin Typing To Search Courses..."
       hx-get="/search-courses"
       hx-trigger="input changed delay:500ms, keyup[key=='Enter'], load"
       hx-target="#search-results"
       hx-indicator="#htmx_search_indicator">

“search-results” with new loading indicator

    <dl id="search-results"></dl>
    <div class="htmx-indicator d-flex align-items-center justify-content-center" id="htmx_scroll_indicator">
      <div style="width: 100px;">
        <!-- SVG goes here -->
      </div>
      <span style="font-size: 24px;">Loading...</span>
    </div>

Now we need to adjust the Liquid side.

The fetchxml query will be restricted to 10 records per page, by using the count parameter and will accept the current page from the query parameters.

The triggering event for the next set of data, will also be specifed as part of this page - when we render the last element of the results, we will check if more records exists, and if true we will add new htmx attribute to the last dd tag, which will be responsible for triggering the next data load. The following attributes will be added:

• hx-get - to tell htmx to perform a GET request with the next page number and search term
• hx-trigger - to tell htmx to trigger when element becomes visible
• hx-swap - to tell htmx to append the respons html after this element
• hx-indicator - to tell htmx to use element with specified id as an indicator

We will also adjust No Results logic - it will only show that message if our query returns 0 results and we are on the first page (to eliminate showing No Results if we have multiple pages).

{% assign pageNumber = request.params['page'] | default:1 %}

{% fetchxml courses %}
<fetch mapping='logical' page="{{ pageNumber }}" count="10">
  <entity name='cr770_course'>
    <attribute name='cr770_courseid'></attribute>
    <attribute name='cr770_coursename'></attribute>
    <attribute name='cr770_description'></attribute>
    <order attribute='cr770_coursename'></order>
    <filter type='and'>
      <condition attribute='cr770_coursename' operator='like' value='%{{params.search}}%'></condition>
    </filter>
  </entity>
</fetch>
{% endfetchxml %}

  {% for course in courses.results.entities %}
    {% if forloop.last and courses.results.more_records %}
      <dt>{{course.cr770_coursename}}</dt>
      <dd 
        hx-get="/search-courses/?page={{ pageNumber | integer | plus: 1}}&search={{params.search}}"
        hx-trigger="revealed"
        hx-swap="afterend"
        hx-indicator="#htmx_scroll_indicator"
        >{{course.cr770_description}}</dd> 
    {% else %}
      <dt>{{course.cr770_coursename}}</dt>
      <dd>{{course.cr770_description}}</dd> 
    {% endif %}
  {% endfor %}

  {% if courses.results.entities.size == 0 and pageNumber == 1 %}
    <dt>No results found</dt>
  {% endif %}

And here is how our implementation of the Infinite Scroll looks.

Conclusion

htmx with Liquid breathes new life into the page interactivity. Obviously, this is not a replacement for Power Pages Web API and custom JS - we will always have complex scenarios and user interactions that the htmx approach cannot solve. However, it is an ideal combo for many easier, most common use cases, allowing you to create beautiful interactive experiences with less code and shorter timeframes.

You can find the full code at my GitHub repo.

Credits

Cover image by Eluj from Pixabay

Animated SVG Preloaders by SVGBackgrounds.com

One of the most common questions I receive is how to perform custom lookup filtering in Power Pages / Power Apps Portals. Even one of my most viewed posts is about this topic. However, that post was written in 2019 and a lot has changed in the last five years (although the question remains the same). So let's revisit that old question and provide an answer on how you can custom filter lookups in 2024.

Approach

First, let's discuss our approach. We cannot filter results in the OOB modal window, as the site returns only a set of records per page. Applying a filter there will yield empty rows or even whole pages. So, we will not use the OOB modal experience at all and instead create our control to handle lookup selection.

In my previous article, I proposed using Form Metadata to render lookup as a dropdown, then fetch the data we need, and replace available options in the dropdown with the data we received. Although this can and will work, there is a big issue with the server-side validation. See, Power Pages validate your submission by comparing the values system originally provided with your submission. If your result was not on the list sent to you originally by the server (which can happen, especially with big datasets) you will have the server-side error.

To prevent this problem, the easiest way is to keep the original lookup control (and not render it as a dropdown), hide it and create a custom control instead, that will present available options and populate the value back to the original control. In this case, the system will only validate if the submitted record belongs to the original query.

Important

Even with a custom control approach you still need to make sure that the value you submit will be included in the view for the lookup control. For example, if the view shows only active records and you try to submit inactive the system will still throw an error.

Custom Control

Now that we know the approach we will take let's see what can we do in terms of the control itself. We cannot use PCF Code Components, as at the time of writing, they aren't supporting Lookups. So, we need to create something on the fly. For this article, we will go with the simplest approach, which will be a basic dropdown, but in actual projects, you can create almost anything. See more complex implementation examples via external library Lookup to Select later in this article.

Before building control, we need to get the data. We have three main ways to get it:

1. Power Pages Web API
2. Custom Page that acts as an API endpoint
3. Cloud Flows

Fetching Power Pages Web API

Power Pages Web API provides a convenient way to get the data you need. You can easily apply filters, sort, etc. When I was writing my previous article, Web API wasn't an option. Right now though, it is the most straightforward way. For this article, we will use Web API in the following example.

However, there are some crucial things you need to consider before going with the Web API approach. The most important one is security. Depending on the type of data you need to get, there might be cases when unfiltered data shouldn't be exposed to the user in any way, shape or form. In those cases, using Web API might not be a choice, as users could just perform a query in the console and obtain information they shouldn't see. Also, when using Web API it is really important to just define the columns your users need to access.

You can learn more about using Power Pages Web API by visiting Microsoft official documentation and my Deep Dive into Web API post.

Fetching with Custom Pages

One of the oldest ways to get data in Power Pages, before the Web API, was using liquid fetchxml requests and custom pages, which will serve as a custom API endpoint.

In short, you create a web template which contains liquid with the necessary fetchxml query. You can configure it to receive parameters and return json as a result, so it will act as our custom web API endpoint.

There are great articles from Colin Vermander (first and second) that explain this concept in more detail. So definitely check them out to learn more.

This approach is better from a security perspective if you need to hide additional filtering criteria and want to make sure your user cannot modify them via the request itself. For example, if you want to filter by users account and don't want them to see it.

Fetching with Cloud Flows

One of the most recent additions to the Power Pages is the ability to call the cloud flows natively. This allows sending and receiving data from Power Automate and performing various actions that not yet available in Power Pages.

This approach is better from a security perspective, especially, if you want to provide access or filter the data that is not available for the portal users.

The downside of this approach is potential licensing cost - Cloud Flows aren't part of the Power Pages licensing and their consumptions and limits might restrict their usage.

To find more about how you can call Cloud Flows from Power Pages visit this official documentation page.

Creating the control

Now that we know how to get the data let's create a control. As stated above, in this example we will be creating a simple dropdown and fetch the data using Power Pages Web API.

// function that will return filtered response
// using Power Pages Web API
function getSampleFilteredResponse(filterCondition) {
  // webapi.safeAjax is a wrapper provided by Microsoft
  // to call Power Pages Web API (you need to manually add it to the page)
  // for the latest wrapper and sample please visit official documentation via link below
  // https://learn.microsoft.com/en-us/power-pages/configure/write-update-delete-operations#web-api-ajax-samples
  return webapi.safeAjax({
    type: "GET",
    url: `/_api/dwctst_countries?$select=dwctst_countryid,dwctst_name&$filter=startswith(dwctst_name,'${filterCondition}')`,
    contentType: "application/json",
    });
}

$(document).ready(async function () {
    const lookupToHideId = "dwctst_country";
    const lookupTableLogicalName = "dwctst_country";
    const idFieldName = "dwctst_countryid";
    const textFieldName = "dwctst_name";
    // hide original lookup
    $(`#${lookupToHideId}`).parent().hide();

    const customLookupId = "my_custom_lookup";
    // create custom select
    const customSelect = $(`<select class='form-control picklist' id='${customLookupId}'>`);
    // place custom select after existing lookup
    $(`#${lookupToHideId}`).parent().after(customSelect);

    // add default selected Select option
    // to mimic OOB select behavior
    customSelect.append(`<option selected="selected" value="" label="Select" aria-label="Select">Select</option>`);

    try {
        let results = await getSampleFilteredResponse("U");

        if (results.value.length > 0) {
            // create an option element for each result
            // and append it to custom select
            results.value.forEach(el =>
                customSelect.append(`<option value='${el[idFieldName]}'>${el[textFieldName]}</option>`)
            )
        }
    } catch (error) {
        // an error occured retrieving data
        // place your error processing logic here
        console.error(error);
    }

    // add onchange event to populate actual lookup
    customSelect.on("change", function () {
        // get selected id
        const selectedValue = customSelect.val();
        // get selected text
        const selectedValueLabel = $(`#${customLookupId} option:selected`).text();

        $(`#${lookupToHideId}`).val(selectedValue);
        $(`#${lookupToHideId}_entityname`).val(lookupTableLogicalName);
        $(`#${lookupToHideId}_name`).val(selectedValueLabel);

        // trigger change event on original lookup
        $(`#${lookupToHideId}`).trigger("change");
    });

});

See example below: only showing countries that starts with "U"

External library - Lookup to Select

To simplify, speed up implementation in complex scenarious and provide users with better experience you can use existing free (like Select2 or jQuery UI Selectmenu) or paid (like Kendo UI jQuery DropDownList) controls instead of simple dropdowns.

I created Power Page Lookup to Select (LtS for short) - a wrapper around the Select2 library. When you call LtS it hides OOB lookup control, creates a new instance of Select2 and an additional select field to hold possible values, and binds the custom select field to OOB control to propagate the value.

See LtS in action below:

To find all the ways you can use LtS please visit the official documentation website.

Conclusion

In this article I described a simle way of filtering lookup:

• hide original control
• fetch data via Power Pages Web API/Custom Fetchxml Pages/Cloud Flows
• create custom dropdown with the retrieved data

You can use this approach on any type of form. Hope you find this article useful.

Cover Image by PDPics from Pixabay

• can we change it to a dropdown?
• can we add search/autocomplete?
• can we show some additional information?

And the answer is usually the same - no. The introduction of custom code components via Power Apps Component Framework gives us a glimpse of hope, however, it is not available for the Power Pages, yet.

What if I told you that you could do all of the above with just a couple of lines of code? Welcome Power Pages Lookup to Select - a jQuery library, that allows you to replace your OOB lookup control with a much more capable Select2 control.

See it in action below:

Visit documentation to find more information on how to get started.

How it works

Power Pages Lookup to Select (LtS for short) is a wrapper around the Select2 library. When you call LtS it hides OOB lookup control, creates a new instance of Select2 and an additional select field to hold possible values, and binds the custom select field to OOB control to propagate the value.

What LtS can do

To find all the ways you can use LtS please visit the official documentation website.

Basic configuration

In the most basic version, LtS provides search/autocomplete functionality

Custom options rendering

LtS allows you to customize how your options are rendered to the user. This can be useful if you want to show additional information to make it easier to select the correct option.

Custom grouping

LtS allows you to provide additional grouping for your option. This can be useful if you want to show additional information to make it easier to select the correct option.

Open source and contribution

This project is open source - so if you have an idea of how to make it better feel free to contribute. There are multiple ways how to contribute:

• open an issue to let us know about bugs or problems
• look into existing issues to help to resolve existing problems
• create a PR for new functionality or enhance existing one

Visit the GitHub repository for more information.

Conclusion

I hope you will find LtS useful. I will continue to maintain and enhance it, and hope the community will do it as well. Visit the official documentation site and GitHub repository for the most up-to-date information on the project.

Snowfall with CSS only

In the first approach, we will be using CSSnowflakes, which is a combination of CSS and HTML without any JS.

This is what our final result will look like:

Let's start by creating a new Web Template called "Snowfall with CSS Only". We will place the following code there:

<style>
/* customizable snowflake styling */
.snowflake {
  color: #fff;
  font-size: 1em;
  font-family: Arial, sans-serif;
  text-shadow: 0 0 5px #000;
}

.snowflake,.snowflake .inner{animation-iteration-count:infinite;animation-play-state:running}@keyframes snowflakes-fall{0%{transform:translateY(0)}100%{transform:translateY(110vh)}}@keyframes snowflakes-shake{0%,100%{transform:translateX(0)}50%{transform:translateX(80px)}}.snowflake{position:fixed;top:-10%;z-index:9999;-webkit-user-select:none;user-select:none;cursor:default;animation-name:snowflakes-shake;animation-duration:3s;animation-timing-function:ease-in-out}.snowflake .inner{animation-duration:10s;animation-name:snowflakes-fall;animation-timing-function:linear}.snowflake:nth-of-type(0){left:1%;animation-delay:0s}.snowflake:nth-of-type(0) .inner{animation-delay:0s}.snowflake:first-of-type{left:10%;animation-delay:1s}.snowflake:first-of-type .inner,.snowflake:nth-of-type(8) .inner{animation-delay:1s}.snowflake:nth-of-type(2){left:20%;animation-delay:.5s}.snowflake:nth-of-type(2) .inner,.snowflake:nth-of-type(6) .inner{animation-delay:6s}.snowflake:nth-of-type(3){left:30%;animation-delay:2s}.snowflake:nth-of-type(11) .inner,.snowflake:nth-of-type(3) .inner{animation-delay:4s}.snowflake:nth-of-type(4){left:40%;animation-delay:2s}.snowflake:nth-of-type(10) .inner,.snowflake:nth-of-type(4) .inner{animation-delay:2s}.snowflake:nth-of-type(5){left:50%;animation-delay:3s}.snowflake:nth-of-type(5) .inner{animation-delay:8s}.snowflake:nth-of-type(6){left:60%;animation-delay:2s}.snowflake:nth-of-type(7){left:70%;animation-delay:1s}.snowflake:nth-of-type(7) .inner{animation-delay:2.5s}.snowflake:nth-of-type(8){left:80%;animation-delay:0s}.snowflake:nth-of-type(9){left:90%;animation-delay:1.5s}.snowflake:nth-of-type(9) .inner{animation-delay:3s}.snowflake:nth-of-type(10){left:25%;animation-delay:0s}.snowflake:nth-of-type(11){left:65%;animation-delay:2.5s}
</style>
<div class="snowflakes" aria-hidden="true">
  <div class="snowflake">
    <div class="inner">❅</div>
  </div>
  <div class="snowflake">
    <div class="inner">❅</div>
  </div>
  <div class="snowflake">
    <div class="inner">❅</div>
  </div>
  <div class="snowflake">
    <div class="inner">❅</div>
  </div>
  <div class="snowflake">
    <div class="inner">❅</div>
  </div>
  <div class="snowflake">
    <div class="inner">❅</div>
  </div>
  <div class="snowflake">
    <div class="inner">❅</div>
  </div>
  <div class="snowflake">
    <div class="inner">❅</div>
  </div>
  <div class="snowflake">
    <div class="inner">❅</div>
  </div>
  <div class="snowflake">
    <div class="inner">❅</div>
  </div>
  <div class="snowflake">
    <div class="inner">❅</div>
  </div>
  <div class="snowflake">
    <div class="inner">❅</div>
  </div>
</div>

snowflake class allows us to change the properties of the snowflakes on our page (like size, colour, etc).

To add more snowflakes you would need to create new divs inside the snowflakes container and update the corresponding CSS (currently each snowflake has its own animation delay and position, so when adding a new one we need to create additional CSS for it).

The aria-hidden attribute is added to the snowflakes container to hide it from screen readers.

Then we will add a Site Setting called Snowfall/Enabled and set it to true. This setting will allow us to turn snow on and off without changes in our code.

Then we will add the following code to the Header web template, so it will apply to all pages with the header

{% assign snowFall_enabled = settings['Snowfall/Enabled'] | boolean %}
{% if snowFall_enabled %}
  {% include "Snowfall with CSS Only" %}
{% endif %}

Snowfall with JS

For the second approach, we will generate our snowfall using JS (from this CodePen).

Our final result will look like this:

We will create a new Web Template called "Snowfall with JS". We will place the following code there:

<style>
.snow-container {
    position: fixed;
    top: 0;
    left: 0;
    overflow: hidden;
    width: 100vw;
    height: 100vh;
    z-index: 99999;
    pointer-events: none;
}

.snowflake {
    position: absolute;
    background-color: white;
    border-radius: 50%;
    opacity: 0.8;
    pointer-events: none;
}

@keyframes fall {
    0% {
        opacity: 0;
        transform: translateY(0);
    }
    10% {
        opacity: 1;
    }
    100% {
        opacity: 0.5;
        transform: translateY(100vh);
    }
}

@keyframes diagonal-fall {
    0% {
        opacity: 0;
        transform: translate(0, 0);
    }
    10% {
        opacity: 1;
    }
    100% {
        opacity: 0.25;
        transform: translate(10vw, 100vh);
    }
}
</style>
<script>
document.addEventListener("DOMContentLoaded", function () {
    const snowContainer = document.querySelector(".snow-container");

    const particlesPerThousandPixels = 0.1;
    const fallSpeed = 1; // controls fall speed
    const pauseWhenNotActive = true;
    const maxSnowflakes = 100; // controls max number of snowflakes
    const snowflakes = [];

    let snowflakeInterval;
    let isTabActive = true;

    function resetSnowflake(snowflake) {
        const size = Math.random() * 5 + 1;
        const viewportWidth = window.innerWidth - size; // Adjust for snowflake size
        const viewportHeight = window.innerHeight;

        snowflake.style.width = `${size}px`;
        snowflake.style.height = `${size}px`;
        snowflake.style.left = `${Math.random() * viewportWidth}px`; // Constrain within viewport width
        snowflake.style.top = `-${size}px`;

        const animationDuration = (Math.random() * 3 + 2) / fallSpeed;
        snowflake.style.animationDuration = `${animationDuration}s`;
        snowflake.style.animationTimingFunction = "linear";
        snowflake.style.animationName =
            Math.random() < 0.5 ? "fall" : "diagonal-fall";

        setTimeout(() => {
            if (parseInt(snowflake.style.top, 10) < viewportHeight) {
                resetSnowflake(snowflake);
            } else {
                snowflake.remove(); // Remove when it goes off the bottom edge
            }
        }, animationDuration * 1000);
    }

    function createSnowflake() {
        if (snowflakes.length < maxSnowflakes) {
            const snowflake = document.createElement("div");
            snowflake.classList.add("snowflake");
            snowflakes.push(snowflake);
            snowContainer.appendChild(snowflake);
            resetSnowflake(snowflake);
        }
    }

    function generateSnowflakes() {
        const numberOfParticles =
            Math.ceil((window.innerWidth * window.innerHeight) / 1000) *
            particlesPerThousandPixels;
        const interval = 5000 / numberOfParticles;

        clearInterval(snowflakeInterval);
        snowflakeInterval = setInterval(() => {
            if (isTabActive && snowflakes.length < maxSnowflakes) {
                requestAnimationFrame(createSnowflake);
            }
        }, interval);
    }

    function handleVisibilityChange() {
        if (!pauseWhenNotActive) return;

        isTabActive = !document.hidden;
        if (isTabActive) {
            generateSnowflakes();
        } else {
            clearInterval(snowflakeInterval);
        }
    }

    generateSnowflakes();

    window.addEventListener("resize", () => {
        clearInterval(snowflakeInterval);
        setTimeout(generateSnowflakes, 1000);
    });

    document.addEventListener("visibilitychange", handleVisibilityChange);
});
</script>
<div class="snow-container" aria-hidden="true"></div>

This version of the code allows you to customize fall speed, number of snowflakes, if snowfall pauses if there is no interaction with the page for some time etc. See the code for the full list of available options.

The aria-hidden attribute is added to the snowflakes container to hide it from screen readers.

Similarly to the CSS-only approach we need to have a site setting to control our snowfall visibility without change to the code. Add a Site Setting called Snowfall/Enabled and set it to true if you didn't do so in the previous example.

Then we will add the following code to the Header web template, so it will apply to all pages with the header

{% assign snowFall_enabled = settings['Snowfall/Enabled'] | boolean %}
{% if snowFall_enabled %}
  {% include "Snowfall with JS" %}
{% endif %}

Conclusion

In this article, I showed you a couple of ways to add a winter spirit to your website by enabling snowfall animation. These code snippets can be further enhanced by adding, for example, a custom button that allows users to enable/disable animation dynamically.

Enhanced Data Model support

Enhanced Data Model recently went GA and brought a lot of changes with it. If you tried to download the site via PAC CLI you might encounter an error saying that a website with a specific id wasn't found. And this is because to download an EDM site you need to specify to the CLI that this is an EDM site. To do so you need to pass the modelVersion 2 parameter to the request so it looks like this

pac powerpages download --path "C:\portals" --webSiteId "site-id" --modelVersion 2

With the latest version of Power Pages Helper, you can now select modelVersion when using Download Portal command.

You also have a new advanced setting to specify the version for the Download Latest command, so when you are using a shortcut it will add the correct model version automatically (see below for the full list of advanced settings).

Migrate to Bootstrap 5

Added support for Migrate to Bootstrap 5 command that allows you to convert an existing portal to Bootstrap 5 (this action will create a new folder with the updated portal).

Advanced Settings

Settings in VS Code

Settings in VS Code have 2 scopes:

• User Settings - Settings that apply globally to any instance of VS Code you open.
• Workspace Settings - Settings are stored inside your workspace and only apply when the workspace is opened.

This allows you to create specific configurations for different projects. For example: if you have one standard portal and one enhanced data model portal you can configure them to use different sets of settings by specifying different Workspace settings.

How to find and configure settings

To get to the settings go to File > Preferences > Settings and search for Power Pages Helper.

There you will see 5 different settings: 3 related to the Download Latest command and 2 related to the Download Portal command.

Download Latest settings

The Exclude Entities setting allows you to provide the list of entities' logical names to exclude during the site download using Download Latest command.

The Include Entities setting allows you to provide the list of entities' logical names to include during the site download using Download Latest command.

The Model Version setting allows you to specify the version of the model to download (1 or 2, where 1 - standard and 2 - enhanced) when using Download Latest command. If not specified, the version 1 will be used by default.

Download Portal settings

Skip Excluded Entities settings allow you to skip the Excluded Entities step during the Download Portal command execution.

Skip Included Entities settings allow you to skip the Included Entities step during the Download Portal command execution.

Miscellaneous

Switched to using the powerpages command instead of the paportal command, as per recommendation from Microsoft.

Conclusion

I will keep evolving Power Pages Helper as I am constantly using it in my projects. If you haven't downloaded this extension already - give it a try to see how it can enhance your developer experience. And if you have any feedback - feel free to hop to the Discussion section of the repository or open an Issue. I would like this extension to be useful for all Power Pages developers, so your feedback matters.

How the Enhanced Data Model works

Enhanced Data Model doesn't have separate tables for many things. Instead, it uses a table called Site Components that holds everything (from Web Role, and Site Settings to Web Files). Then Microsoft uses plugins and some magic to present those records as separate tables via Virtual Tables. So the Web Role that you see for the Enhanced Data Model (table name mspp_webrole) is actually just an abstraction on top of the Site Component table. Microsoft just presents it to use as separate tables in a familiar interface.

How to find currently assigned roles

Previously, when you tried to find Web Roles assigned to a contact, you would go to the Related tab on the Portal Contact form and select Web Roles. However, if you do it now, it will show you the old adx_webrole table. Unfortunately, you cannot show the virtual table in the Related section.

To view roles, currently assigned to a contact, open a contact using the Portal Contact (Enhanced Form) form, and navigate to the General tab > Web Roles section. There you will see a list of already assigned roles and can assign new ones as well.

How to dynamically assign roles

Previously, with the Standard Data Model, when you wanted to dynamically assign a web role, you would use, for example, Power Automate to associate the Contact table with the Web Role table via adx_webrole_contact relationship. But, with the Enhance Data Model, you need to use the Site Component table instead. On the Contact table, you have the Relationship called powerpagecomponent_mspp_webrole_contact which links the Contact and Site Component table. Use that relationship and the odata id of the web role (mspp_webrole one) to associate the table (you can get the Odata id if you get that web role via Get Row action or in the next format https://ORGNAME.crm.dynamics.com/api/data/v9.1/mspp_webroles(GUID).

How to dynamically remove roles

Similarly, to how we associated web roles we can dynamically remove them using Power Automate. This time, however, we need to get odataid of the Site Component behind the Web Role. To do so you can first query Web Role by name and then query Site Component by id or if you know that id query it directly. After getting odataid we need to perform an Unrelate action from the contact to the Site Component table via powerpagecomponent_mspp_webrole_contact relationship.

Conclusion

Enhanced Data Model is a big shift to make Power Pages more aligned with the usual ALM story for Power Platform, more performant and easier to update. And, although, from the surface, things might look the same, under the hood a lot has changed. This includes changes to the Web Roles and how we interact with them. In this article, you found how you can find current associated roles and how to dynamically assign new ones. Hope you find it useful.

Action plan

We will add a file input to a webpage. On file load, we will call a cloud flow. This flow will accept a file input (image), save that file as a note, get that note from the system back and return it to Power Page to show the image on the screen.

Creating a flow

First, we need to create our cloud flow. To do so open the solution you want to create your flow from (as you can only call solution-aware flows from Power Pages). Select When Power Pages calls a flow as your trigger action. There you can select your inputs. For this sample, we will select two: file input called customFile and text input called customTextField.

Next, we need to create a new note. We will select the Add Row action, select Notes as our Table and provide Title, DocumentBody (which is file content) and FileName. To get the file name we will use the next expression triggerBody()?['file']?['name']. To get the file body we could use the provided customFile option, however, because our file content is base64 string system sometimes throws the error when parsing ("Invalid character in field 'documentbody': '.', hexadecimal value 0x00, is an invalid character."). To avoid this problem we can encode and decode string directly using the next formula: decodeBase64(base64(triggerBody()?['file']?['contentBytes'])).

Now when the note is created let's retrieve it back from the system.

Last we need to return values to Power Pages: in responseFile output, we will return our image from the newly created note and in responseText output, we will return "Some returned text".

Now our flow looks like this.

Let's move to the Power Pages part.

Add cloud flow to Power Pages

In Power Pages Studio navigate to the Set up section and select Cloud flows under integration. Select Add existing flow, choose newly created flow and select Web Roles that will be allowed to call the flow.

After that click the Copy icon in the URL field to copy the URL of the flow. We will use it later to call the flow from the code.

Call flow from Power Pages

Open a page from which you want to call the flow. In this example, I will use VSCode online for code editing.

Let's add the next HTML code: simple file input ( with the sendAndReceiveFile function that will be triggered on the change event), an image to show the returned file and some explanation text.

<p>Choose a file to save as a note in the system</p>
<input type="file" name="" onchange="sendAndReceiveFile()" />
<img id="returnedImage" />

First, we need to manage our file input. We will create a function called sendAndReceiveFile which will create a new file reader and read our file as a data URL (we need this as flow accepts files as base64 encoded string).

  function sendAndReceiveFile() {
    // get our input
    const file = document.querySelector("input[type=file]").files[0];
    //initialize new file reader
    const reader = new FileReader();

    // trigger sendToFlow function
    // when file reading ends
    reader.addEventListener(
      "load",
      () => {
        // get base64 string without 'data:image/jpeg;base64' part
        const base64str = reader.result.split(',')[1];
        sendToFlow(file.name, base64str);
      },
      false,
    );

    if (file) {
      // read file from our input as base64 encoded string
      reader.readAsDataURL(file);
    }

  }

Next, we need to create a function which will call the flow itself. We will call it sendToFlow and will accept the file name and base64 encoded file body.

We need to form a request object. First, we create an object with our inputs. The name of the inputs should be the same as in the Power Pages trigger. File input should be an object with two properties: name - to hold the name of the file and contentBytes - which will contain base64 string.

    let data = {
      customTextField: "Hi, I am text from site",
      customFile: {
        name: fileName,
        contentBytes: b64str
      }
    };

The request object itself should only have one parameter eventData - which should be a stringified version of the object with inputs.

    let requestObj = {
      eventData: JSON.stringify(data)
    };

To call the flow I will be using shell.ajaxSafePost method provided by MS - this way I don't need to worry about adding a CSRF token to my requests. However, you are free to use fetch or another way to create a POST request as long as you handle token generation and include it in the correct header with the request.

The URL for the request would be a simplified version of the URL we copied when we configured cloud flow. We removed a part before /api to make it universal and avoid issues with environment-specific deployments.

    shell.ajaxSafePost({
      type: "POST",
      contentType: "application/json",
      url: "/_api/cloudflow/v1.0/trigger/YOUR_CLOUD_FLOW_GUID",
      data: JSON.stringify(requestObj),
      processData: false,
      global: false
    })
      .done(function (response) {
        handleFlowResponse(response);
      })
      .fail(function (er) {
        console.error(er);
      });

Last, we need to create a function that will handle the response from the flow. handleFlowResponse will parse the returned string as an object. This object will contain our outputs. IMPORTANT - as of now returned object have our output name in lowercase so make sure you use the correct names. Let's add our returned image to the page and observe the result.

  function handleFlowResponse(response) {
    const responseObj = JSON.parse(response);
    console.log("responseObj", responseObj);
    const previewImg = document.getElementById("returnedImage");
    previewImg.src = "data:image/jpeg;base64," + responseObj.responsefile;
  }

RESULT

Below you can find small demo of sending and receiving file form cloud flow:

ERRORS AND ISSUES

When you call the flow you might receive an error that input parameters are in incorrect format. Please check your flow as an error might be caused by problems in other parts of the flow unrelated to the inputs.

IMPORTANT Currently, there is an issue with sending files more than 2mb in size. You will get: "Error during serialization or deserialization using the JSON JavaScriptSerializer. The length of the string exceeds the value set on the maxJsonLength property. Parameter name: input". Microsoft was notified about this problem.

Potential workaround: thanks to Lyle Stanton for suggestion.

To avoid this issue try to not provide contentType explicetly, remove processData and global from the ajaxSafePost request and do not stringify request object

  function sendToFlow(fileName, b64str) {
    // create object with inputs
    // file input should have both name which holds filename
    // and contentBytes which holds base64 string representation of the file
    let data = {
      customTextField: "Hi, I am text from site",
      customFile: {
        name: fileName,
        contentBytes: b64str
      }
    };

    // actual request object should have only one parameter
    // called eventData which shoould be stringified
    // version of the object with inputs
    let requestObj = {
      eventData: JSON.stringify(data)
    };

    // I am using ajaxSafePost as it automatically adds
    // CSRF token, however, you can use fetch or other method
    // as long as you manually handle getting the token
    // and adding it to appropriate header
    shell.ajaxSafePost({
      type: "POST",
      contentType: "application/json",
      url: "/_api/cloudflow/v1.0/trigger/YOUR_CLOUD_FLOW_GUID",
      data: requestObj,
    })
      .done(function (response) {
        handleFlowResponse(response);
      })
      .fail(function (er) {
        console.error(er);
      });
  }

CONCLUSION

Cloud flows in Power Pages are a huge addition to the product, which extends its capabilities tremendously. And the addition of File type input pushed it even further. Calling cloud flows from the site is quite straightforward, however, documentation around it could be better. I am happy the product is growing, and moving forward will be using Power Automate to achieve even more. Hope you find this article useful.

Full code

<p>Choose a file to save as a note in the system</p>
<input type="file" name="" onchange="sendAndReceiveFile()" />
<img id="returnedImage" />
<script>

  function handleFlowResponse(response) {
    const responseObj = JSON.parse(response);
    console.log("responseObj", responseObj);
    const previewImg = document.getElementById("returnedImage");

    //using lower case responsefile instead of responseFile
    //as currently cloud flow returns everything lowercase 
    previewImg.src = "data:image/jpeg;base64," + responseObj.responsefile; 
  }

  function sendToFlow(fileName, b64str) {
    // create object with inputs
    // file input should have both name which holds filename
    // and contentBytes which holds base64 string representation of the file
    let data = {
      customTextField: "Hi, I am text from site",
      customFile: {
        name: fileName,
        contentBytes: b64str
      }
    };

    // actual request object should have only one parameter
    // called eventData which shoould be stringified
    // version of the object with inputs
    let requestObj = {
      eventData: JSON.stringify(data)
    };

    // I am using ajaxSafePost as it automatically adds
    // CSRF token, however, you can use fetch or other method
    // as long as you manually handle getting the token
    // and adding it to appropriate header
    shell.ajaxSafePost({
      type: "POST",
      contentType: "application/json",
      url: "/_api/cloudflow/v1.0/trigger/YOUR_CLOUD_FLOW_GUID",
      data: JSON.stringify(requestObj),
      processData: false,
      global: false
    })
      .done(function (response) {
        handleFlowResponse(response);
      })
      .fail(function (er) {
        console.error(er);
      });
  }

  function sendAndReceiveFile() {

    // get our input
    const file = document.querySelector("input[type=file]").files[0];
    //initialize new file reader
    const reader = new FileReader();

    // trigger sendToFlow function
    // when file reading ends
    reader.addEventListener(
      "load",
      () => {
        // get base64 string without 'data:image/jpeg;base64' part
        const base64str = reader.result.split(',')[1];
        sendToFlow(file.name, base64str);
      },
      false,
    );

    if (file) {
      // read file from our input as base64 encoded string
      reader.readAsDataURL(file);
    }

  }
</script>

Before we begin I would like to highlight that currently, this feature is in Preview status meaning it is not suitable for production. Although the GA date is set for November of this year I would advise to really test it out before moving to production.

How to migrate

First, we need to enable Bootstrap 5 for our environment. To do so go to Power Platform Admin Center, select an environment that you need, and in the Resources tab select Power Pages sites, then in the header select Enable Bootstrap v5 for new sites (preview).

Next, we would need to use PAC CLI to convert our site to use Bootstrap 5. Microsoft will not automatically convert your existing website to keep backward compatibility. Instead, they provide a new command pac powerpages bootstrap-migrate to migrate your site.

Connect to the environment you want via PAC CLI (either via auth command or through Power Platform Tools extension). Download your website via the pac powerpages download command. Then run pac powerpages bootstrap-migrate -p "path-to-your-folder". You can also use my Power Pages Helper extension to invoke this command.

Bootstrap-migrate will create a new folder with the Bootstrap 5 version of your site. In the folder,beside the updated portal, you will find a logs.txt document which will highlight which files were changed by the migration tool. This is useful for troubleshooting, validation and general knowledge purposes. For example, I have a template called bootstrap3-test that uses a Bootstrap 3 carousel for images. After migration in logs.txt, I can find a detailed description of which classes were removed or replaced with their Bootstrap 5 alternatives.

Also in the Site Settings file, you can find a new setting called Site/BootstrapV5Enabled which says site to use Bootstrap 5.

After migration we just need to upload the updated version back to the system using the pac powerpages upload command and enjoy new styles.

Version comparison

Main Page and Navigation Menu Bootstrap 3

Main Page and Navigation Menu Bootstrap 5

As you can see after migration navigation looks more condensed and paddings around links are completely different. Also, the logo and company name are shifted to the right.

Contact Us form Bootstrap 3

Contact Us form Bootstrap 5

Form controls look almost the same, but in the Bootstrap 5 version, they are more rounded by default.

As you can see not everything went smoothly - the navigation menu after migration requires additional CSS styling to look good. So be careful and make sure you inspect all pages as your styling might break in unexpected places.

Other changes

Beyond Bootstrap 5 Microsoft also updated icons to use Font Awesome 6 - so you can enjoy a bigger selection of icons, styles and improved performance.

Conclusion

Bootstrap 5 was long awaited update for Power Pages. This change will allow us to create more complex and modern-looking websites. However, the transition isn't smooth and will require effort to ensure that migrated styles work as well as the originals.

The old way

Power Platform environment configurations allowed us to manage the list of blocked extensions for quite some time. To do so you need to go to your environment, click Advanced Settings > Settings > Administration > System Settings. There in the General tab, you will see a list of the blocked extensions for the attachments.

However, in my case, there was no svg there already. So what was blocking my file upload? Well, the new UI gives us more options to control extensions.

The new way and solution

Let's go to the Power Platform Admin Center, and select an environment that we need. In the environment go to Settings, expand the Product section and click Privacy+Security. There are 3 options which allow you to control files for the environment:

• Blocked Attachments - this same option as before where you can provide a list of blocked extension fields
• Blocked Mime Type - a new option allows you to block specific mime types allowing more granular control over attachments
• Allowed Mime Types - a new option which is useful when you have only a couple of mime types that should be allowed in your system. This will take precedence over the Blocked Mime Types option.

The second option was a culprit in my case as image/svg+xml was set in this field preventing svg upload to the system. Clearing up "Blocked Mime Type" resolved the problem.

Conclusion

So to reiterate - if you have an "XRM Network error operation not allowed as mime type is blocked" issue go to the Power Platform Admin Center and make sure that your file's mime type is not in the list of blocked attachments or mime types (or added to the allowed mime type list if your environment has stricter level of security). Hope this will help.

Solution context in Maker Portal

If you ever created new things in Dataverse (like Tables, Apps, Web resources etc) directly via Maker Portal, outside of the specific solution, those changes would automatically appear in the so-called Common Data Services Default Solution with default publisher prefix. Although experienced creators are aware of this behaviour and are working in predefined solutions, new makers and developers might not know or expect this, which can lead to the necessity to recreate and rebuild some things.

Luckily we will be able to change that soon with the new ability to select any other unmanaged solution as the active solution context. More importantly, this will set the publisher from that solution as the default one as well (no more random cr6eb20 anymore). This will help to promote easier usage of the Maker Portal, better customization hygiene and create a setup for more successful application lifecycle management.

Admin will be able to configure this feature in Public Preview from Oct 2023. There is no GA date yet. The original announcement can be found here.

Clean data with AI

Microsoft is truly becoming an AI company and bringing AI everywhere. Microsoft understands the value of good quality data, so this time it brings AI to the Dataverse to help with data cleanup tasks in the form of the smarter data layer and data hygiene suit. So far we don't have a full description of what a "smarter data layer" exactly will be, but according to Microsoft - a smarter data layer will be infused with AI models, to allow the makers to create smarter and context-aware apps with better data quality.

In regards to the data hygiene suite MS says that it will include semantically smart data validation for email and phone numbers, smart data deduplication rules, and native content AI experiences fully integrated into Dataverse and Power Platform to complete the data-insights-action loop.

This feature will start with email-type columns to help bring more sophisticated email validation that will include the reason why the data entry is invalid. This will help both users and admins to maintain a higher quality of the data on a proactive basis.

I hope that in the future this feature will allow us to configure our smart data layer for custom fields with custom validation which will help to improve data quality drastically and resolve so many different scenarios. But unfortunately, at least for now, we don't have any more details about this feature or its future.

It will become GA for all users in Mar 2024. The original announcement can be found here.

Power Pages Copilot

Image by ClaudeAI.wiki

Another feature - another AI infusion. This time it is for Power Pages. Previously MS brought Copilot to Power Pages to help with Form creation. This time scope is bigger and consists of next things:

• site creation
• Q&A to help build the site
• Copilot actions for end-users

Site creation

Let's start with site creation. You just need to describe what website you want to create and Copilot will generate it for you - including sitemap, different pages, home page layout and theme. If you don't like the suggestion you could ask Copilot to regenerate them or use it later to refine it.

As of now, we don't know how specific Copilot would be (ie can we generate a Home page with a specific layout or in the context of the specific company theme), but regardless it will simplify initial website creation drastically and allow for more time spent on refining and making the website look better than long initial creation process. I hope that in the future we will have the ability to create even more with Copilot like specific pages and more.

This feature will be available for Public Preview in Oct 2023. The original announcement can be found here.

Q&A

With this feature you won't need to leave Power Pages Studion anymore to find more information - just ask Copilot. Q&A will summarize the information that is spread across Learn, community, and other key resources (maybe even this website, who knows) to answer makers' questions regarding everything Power Pages to unlock better website creation with less hassle.

This feature will be available for Public Preview in Oct 2023. The original announcement can be found here.

Website Copilot Actions

Right now you can easily enable the Power Virtual Agents chatbot for your Power Pages site. But this feature takes it to the next level - Website Copilot Actions will allow your Power Pages users to ask the chatbot for help to complete actions like filling simple forms with basic validation in place, finding and getting redirected to resources on the website, and more.

This will be a huge boost for both end-user experience and site accessibility. Unfortunately, we don't know how easy would be to configure specific actions and scenarios, whether can we use existing chatbots, etc. But this sounds amazingly promising and I cannot wait to try this one out.

This feature will be available for Public Preview in Nov 2023. The original announcement can be found here.

Low-code plugins

As somebody said when Power FX was first introduced - it will be everywhere. And seems like that prediction is becoming a reality with the introduction of low-code plugins. You will be able to create a real-time server-side plugin using Power FX. They will have almost all sets of capabilities of the Power FX from the canvas app (although not all) and will behave similarly to the Dataverse Custom Actions and APIs.

This doesn't mean that you need to abandon your good old C# plugins and rewrite your current logic with Power FX. Low-code plugins have a particular use-case scenario in mind - to shift complex logic and calculation from canvas apps to the server. It is not a secret, that code for canvas apps can grow out of proportion and need a lot of hacks and tricks to ensure stable performance. Moving complex logic from the app to the server will lead to a boost in performance and a better user experience.

Low-code plugins will be available in canvas apps for Public Preview in Sep 2023 and should go GA in Dec 2023. The original announcement can be found here and here.

Bootstrap 5

Bootstrap 5 for Power Pages is the most requested feature from the community. Originally announced as part of 2023 Release Wave 1 it shifted to this Release Wave. But hopefully this time it will stay.

Update to the latest version includes a bunch of benefits (like security fixes and UI improvements) but also allows a lot of new front-end developers to start with Power Pages more easily (as they might be more familiar with the most recent version of Bootstrap).

You will be able to migrate your existing Power Pages site to V5 using the PAC CLI tool (available from version 1.23 but you still need a backend update as well). The tool will create a local copy of your site with changes to V5. Keep in mind that it will only convert standard Bootstrap classes so if you created some custom things you would need to update them manually.

For some time Power Pages will support both V3 and V5, but eventually, everyone will need to migrate. For now, we don't know what will be the deprecation date (but knowing Microsoft it will be somewhere close to the end of 2024 or even 2025).

This feature will be available for Public Preview in Jul 2023 and GA in q. The original announcement can be found here.

Conclusion

In this post, I highlighted the features that I think are the most interesting in the upcoming release. AI is changing how we can interact and create things in the Power Platform and it is exciting - cannot wait to try these features out. But other awesome things are waiting for you in the documentation, so check it out.

Automated testing for model-driven apps

Running tests is important for any large-scale app development. They ensure the reliability and stability of your code. However, testing your UI was always a more problematic solution, especially if you do not have a dedicated team or specific tools. To tackle this some time ago Microsoft introduced Test Studio which allowed the creation of multiple testing scenarios for Canvas apps using Power FX. And now we finally will have the same capability for model-driven apps and custom pages. Utilizing the power of Playwright enhance Test Engine should allow for faster, more complex and robust testing.

Elevating this to the next level is the ability to run tests as part of your CI/CD pipeline. PAC CLI, Azure DevOps and GitHub Action will support running an updated Test Engine.

Both of these features will be available in Public Preview in May 2023. There is no GA date for now. The original announcement for the test studio can be found here and for CICD pipeline support here.

Create virtual tables easily in Maker Portal

The virtual tables are part of the Power Platform for quite a while. However, from the beginning virtual tables had a lot of restrictions and were mostly accessible by developers only. Gradually more and more features were released making virtual tables a more valuable and effective component. And now one big step to make them more accessible has been made - makers can create a virtual table through the maker portal UI. A guided, step-by-step process will allow users to create a virtual table just in a few clicks. The new editor will also allow to create relationships between virtual and regular Dataverse tables.

This feature will be available for Public Preview in Jan 2023 and should be GA in Jun 2023. The original announcement for the test studio can be found here.

Refreshed model-driven and canvas apps UI

Model-driven and canvas apps will receive a UI update to align them with the latest changes in the Microsoft Fluent UI design system. This will include controls, fonts, colours, icons and more. For both model-driven and canvas, it will be an opt-in feature, so if for some business or other needs you need to keep your old design there is nothing to worry about. Changes will be gradual and things will be updated as MS will introduce new updates to the Fluent UI. This should make the design more modern and up-to-date overall.

For model-driven apps, Public Preview will start in Jan 2023 with GA in Apr 2023. For canvas apps, Public Preview will start in Feb 2023 with GA in Jun 2023. The original announcement for model-driven can be found here and for canvas here.

Cloud flow in Power Pages

Calling cloud flow from Power Pages was possible for quite some time, however not in easy to use and manage fashion. You needed to create HTTP-triggered cloud flow, maintain different URLs between environments, and think about the security of your calls. All of that made the task of using cloud flow in Power Pages unnecessarily complex. With this release, this no longer will be the case - welcome native cloud flow in Power Pages.

A new connector will be available in Power Automate that will allow to create a cloud flow that can be easily and securely invoked from Power Pages. This connector will also support bi-directional data exchange which in many scenarios is a necessity for Power Pages.

Right now we don't have details about what endpoint we will need to use to invoke cloud flow or how exactly we will manage security, but I am excited about this feature as it will allow many citizen developers to create secure and custom endpoint enhancing Power Pages capabilities even more.

This feature will be available for Public Preview in Jun 2023. No GA date yet. The original announcement for this feature can be found here.

Bootstrap 5

Power Pages uses Bootstrap 3 as its CSS framework of choice. And let me tell you - upgrading from Boostrap 3 to a newer version was the number 1 request from the community for a long time. And finally, it is happening - Power Pages will start using Bootstrap 5 OOTB. Hooray!

Update to the latest version includes a bunch of benefits (like security fixes and UI improvements) but also allows a lot of new front-end developers to start with Power Pages more easily (as they might be more familiar with the most recent version of Bootstrap).

Power Pages will also provide you with a migration tool to upgrade your code to the latest version. The tool will provide reports on what was changed, so you can control and update code if necessary.

This feature will be available for Public Preview in Jun 2023. No GA date yet. The original announcement for this feature can be found here.

ALM Power Pages using solutions

ALM in Power Pages was always a tricky thing - from the get-go, you needed to separate your solution with Dateverse tables, plugins etc, and your portal configuration (web pages, web files, etc). With the introduction of PAC CLI support for Power Pages things became easier, but still, data lived separately. Well, all of this is about to change.

Introducing support for Power Pages in solutions. Finally, they will start to feel like a full part of the Power Platform. At this time we don't know how much we will actually include in the solution (only the website record or the whole configuration) or how PAC CLI will work with it. However, I am excited to see how much this will simplify ALM and help new developers and makers get started with Power Pages ALM more easily in a more familiar manner.

This feature will be available for Public Preview in Apr 2023. No GA date yet. The original announcement for this feature can be found here.

Dependent assemblies in plugins

ILMerge no more! The ability to use external assemblies in your plugins became available in Public Preview back in Mar 2022. This was a big breakthrough as using an unsupported and hack-y way of ILMerge was considered not the best, but unfortunately, in many cases your only choice when you needed some external assemblies in your code. During the last year we patiently waited for the GA - and now we have it. Dependent assemblies should be GA in Apr 2023.

The original announcement for this feature can be found here.

Data ingestion optimizations

There is plenty of scenarios when you need to perform various bulk operations. And as a developer, you are always in search of how you can make those operations as performant as you can to smooth your user experience. Well, now we have new messages just for this purpose: CreateMultiple, UpdateMultiple and UpsertMultiple.

There are 3 key improvements:

• these messages apply the change to the database for all records at the same time, not sequentially;
• common internal operations will be performed once for each request rather than for each row;
• you will be able to apply custom business logic in the plugin that will be invoked just once for a request and applied to all records in it.

These messages will not replace existing bulk methods like $batch or ExecuteMultiple. New messages cannot continue on error as operations are performed simultaneously not per row bases. Because of that, you should use new messages when you are sure that bulk operation will not fail and you need to optimize the performance.

Create and Update messages aren't deprecated, however, Microsoft recommends switching to CreateMultiple and UpdateMultiple messages respectively and updating your plugin code if additional performance is needed for certain tables.

Overall, this will spark a huge shift in plugin development and I am curious to see how this will go.

You might notice that there is no DeleteMultiple. This is because the Delete operation often involved cascading operations which cannot be properly evaluated and acted upon in the limited period of execution.

This feature will be GA in May 2023. The original announcement for this feature can be found here.

Conclusion

In this post, I highlighted the features that I think are most interesting in the upcoming release. I am excited as there are many features that were requested for a long time and a lot of overall improvements. But there are much more changes waiting for you in the documentation, so check it out.

Screenshots of new functionality are taken from Microsoft release wave documentation.

CSS to the rescue

So how we can hide fields by default without using JS? Using CSS may sound obvious, until we take a look at how the fields are rendered on Power Pages. Let's say we have a couple of fields (Issue Type, Issue Severity and Feature Priority) that should be hidden by default and later conditionally shown.

Let's take a closer look at the Issue Type (crfbd_issuetype). This is a simple text field. Usually, websites render text fields like label/input combo. But in Power Pages it looks a bit different (simplified HTML):

<tr>
<td>
    <div class="info">
        <label for="crfbd_issuetype" id="crfbd_issuetype_label" class="field-label">Issue Type</label>
    </div>
    <div class="control">
        <input type="text" maxlength="100" id="crfbd_issuetype" class="text form-control " >
    </div>
</td>
</tr>

As you can see label and input itself are in different containers. We can hide them by targeting input and label independently, but we would have an empty tr which wouldn't look nice on the form. So ideally we would need to somehow target their common parent. But there is no parent selector in CSS. Or is it?

Welcome :has. This selector allows you to target the parent or relative sibling of something. This opens the door for a wide variety of interesting styling options, including hiding the parent when some conditions satisfied for the child. Learn more about :has pseudo-class here.

In our case, CSS would look simple - tr as the tag name and id as a selector:

tr:has(#crfbd_issuetype) {
    display: none;
}

And that's it - now your fields are hidden by default, no JS necessary. Below you can find a small demo:

Additional bonus - they are also hidden in the Power Page editor.

Caveat

But this approach has a caveat. And in this case, it is a support across browsers. According to caniuse - Firefox and some mobile browsers (like Opera Mini or Samsung Browser) don't support this pseudo-class. So to make sure it will work always I would advise using both CSS and JS - if the browser doesn't support :has JS will do the trick.

Conclusion

Now we have a clear way to hide fields by default using some CSS magic. And we can still use JS to ensure that it will work across the browsers.

However, some things are getting lost in this big announcement. That's why I decided to write about 3 new, awesome and maybe a bit overlooked features:

• Content Delivery Network or CDN
• Web Application Firewall
• Content Security Policy

CDN

So what is a CDN? Well in short a content delivery network is just a group of servers that are located in different geographical locations that deliver Internet content (CSS and js files, images and videos, and other static content) to a user faster by serving a cached version of the content from locations that are physically closer to the user, which reduces latency and improves overall website performance.

CDN is a really popular way to improve your website performance. Here are some statistics about CDN usage:

• A CDN can also decrease website latency by an average of 83%.
• Using a CDN can take a load of 60% or more off your origin server.
• Using CDN can boost a website's SEO score.

Having said that, enabling CDN might not boost performance significantly for every website. For example, CDN for Power Pages doesn't serve files that are under the pages that are protected by Web Page Access Control rules for security reasons. This means if you have a website with a lot of private content your performance might not be boosted as much as a website that has a lot of public-facing images, videos etc.

Overall, I would say you should definitely enable CDN for Power Pages as any performance improvement and latency reduction is a positive thing for your user. Plus you don't need to pay for this feature, which is a great competitive advantage over other similar services.

You can find more about how to enable CDN in the official documentation here.

Web Application Firewall

The next awesome feature for Power Pages is the Web Application Firewall. In short, WAF help to protect your website by monitoring and filtering HTTP traffic between your website and the Internet. You can imagine it as a set of rules that find and blocks common malicious attacks.

Web Application Firewall for Power Pages is powered by the same technology as a CDN for Power Pages - by Azure Front Door - which in itself is a Microsoft CDN system.

Important

To be able to use WAF you need to enable CDN first.

Currently, WAF for Power Pages protects you against the next type of attacks:

• Cross-site scripting
• Local file inclusion
• Remote file inclusion
• Session fixation
• Protocol attackers
• Protocol enforcement

Unfortunately, as of now, you cannot configure the set of rules that are available for WAF, but even the initial set is covering the most common scenarios.

Overall, it is an awesome addition, that allows users to improve the security of the Power Pages without the need to understand how exactly WAF works and reduce implementation overhead. And the fact that you can enable this in one click is just the cherry on top. You can find more about how to enable WAF in the official documentation here.

However, if you do need to have more extended security and CDN capabilities you can always configure the core technology itself - Azure Front Door and connect it to your Power Page. To find out how to do that check this official documentation.

Content Security Policy

Last in this article, but certainly not on the list overall is Content Security Policy or CSP. It is another great addition to the Power Pages security.

Content Security Policy allows you to specify a set of directives or rules, that help to control which resources (ie script files, CSS files etc) your website can load and from which sources. This helps to mitigate some common attacks like the distribution of malware or data theft.

If you were working with Power Apps Portal for a while you might say that CSP was part of the platform for a while. Indeed, now, the same as before, you need to configure HTTP/Content-Security-Policy site setting to make it work. However, previously this setting was hidden inside the documentation, often obscured and unexplained for regular users. Now, however, we finally have a clear reference on how and why you should use it in the platform.

You can find more about how to enable CSP in the official documentation here.

Conclusion

Power Pages is an awesome evolution of an existing product that brings a lot of new and awesome features to the table. I really like, that with the platform growth it offers more in terms of security and performance, which will help it to stand up against the competition.

Download command

Before this release, when you downloaded the portal it was always all of it with all tables and files. Generally, this is not a huge problem and loading time is in the range of 30+ seconds. However, I saw projects, especially with older portals, with huge amounts of web files and pages where loading times were outrageous (the worst one downloaded portal in 5 min). And there was no way to solve this. But not anymore. Welcome release 1.17.5 and new optional parameters for download command - includeEntities and excludeEntities.

For both of these parameters, you need to specify a list of comma-separated entity logical names. Include entities will define which entities the portal should download and will skip all others. Exclude entities will define which entities to omit during the download.

The example command will look something like this:

pac paportal download -p "c:\demo" -id guid -ie "adx_entityform,adx_webpage,adx_webtemplate"

The addition of those parameters makes using CLI much more effective, especially in edge case scenarios where portals are just too big to deal with them effectively. Also, if working in branches, it opens the door for the possibility of just loading entities that you will be working on (like content snippets, templates etc).

But what if you don't want to memorize the entity's logical name? Or don't want to mistype them? Well, the new update for my Portal VS Code extension might help you with that.

Portal helper to the rescue

Portal Helper is an extension that I developed to help users to work with Portal CLI more efficiently. With this update, I am adding two new things.

Firstly, the Download command now supports both include and exclude entity parameters. More importantly, instead of the free text option, it is a selection of all available entities, by their friendly name, so you don't need to remember logical names and can just select them from the list.

Secondly, my Download Latest command, which downloads the portal from the current folder, now supports setting include and exclude parameters in the VS Code settings. You can do this both on a global level or on a workspace level (meaning you can have different configurations for different portals).

To set those setting navigate to Settings and type Portal Helper. You will see two options available to you.

Conclusion

I am really happy that MS continues to develop the portal part of MS Power Platform CLI allowing us to do much more. With each release, it becomes easier and more convenient to work inside VS Code. And I will continue to improve my extension to make VS Code experience even better.

Version 1.0.0.0

The main purpose of this control is to simpify your work with advance (web) form steps, by allowing you to visualize their order and connections, update it, create new steps, update and delete existing.

Important

This control will not replace regular experience. You still need to open web form steps to add metadata, specify forms that should be used, etc. Control just simplifies general management of steps.

With Web Form Steps Visualizer you can perform next operations:

• Create new steps
• Update existing steps
• Delete steps
• Open step in a new tab
• Delete connection between step - this action clears lookup of target step to remove reference of the next step (or default next step for conditional step). To perform this you need to click on connection line (it will turn blue), then click Backspace on your keyboard, and then click Save changes button.

You can find demos of each action below.

You can find and download the latest version from Release page of my Github repo.

Demo

Create new step

Update existing step

Update connection

Delete step