Custom JavaScript and Liquid in Power Pages Without Breaking on Refresh

Why does custom JavaScript disappear or stop working in Power Pages?

There are four common causes, and only one of them is the code actually being deleted.

The first is code pasted as a script tag into the page copy through the design studio text editor or a copy of the HTML. The studio treats page copy as content it owns, and a later visual edit can reformat or strip markup it does not expect. The second is timing: lists and some form elements render after the page loads, so a script that runs on page load finds nothing to attach to and appears to work only on some refreshes. Multistep forms also post back and redraw the page, so handlers attached once are gone on the next step.

The third is editing the wrong record. On sites with language support, a page has a root record and a localised content page, and the site renders the content page. Script typed into the root page in the Portal Management app does not appear, and script typed into one language does not appear in another. The fourth is caching: web files and page content are cached by the site and the browser, so a change can look lost until the cache refreshes. Check current Microsoft documentation for how to clear the site cache in your version.

Where can custom code legitimately live in Power Pages, and which places survive design studio edits?

Every place below is supported. The difference is who else edits it and what the studio regenerates. Put behaviour in places developers own, and keep content editors in places that hold content.

How should shared JavaScript be structured across dozens of pages?

One bundle, loaded once, doing nothing until a page asks for it. Copying the same fifty lines into the custom JavaScript of thirty pages is how a fix gets applied to twenty-eight of them.

Build the site script as a single file, bundled and minified if you use a build step, and upload it as a web file such as /js/site.js with a version in the reference so browsers fetch the new copy. Load it once from the layout. In your page templates, write a data attribute on a wrapping element, for example data-page="case-detail", using a value set in the web template or read from a site marker. The bundle then looks up a small registry of initialisers by that value and runs only the matching one.

That leaves each page's own custom JavaScript either empty or a single call with page-specific settings. What the file weighs and how it loads is covered in our Power Pages performance guide; defer the script and keep libraries out of the bundle unless most pages use them.

• Wrap everything in a namespace such as window.Site, and never rely on global variables from other pages.
• Keep one initialiser per page type, each checking that its elements exist before touching them.
• Wait for lists to finish rendering by handling the list's loaded event rather than page load, and reattach form handlers after every multistep form postback.
• Delegate events to a stable parent element so re-rendered rows keep their behaviour.
• Log errors to the console with the page type, and send them to Application Insights if you use it, so a broken initialiser is visible instead of silent.

How do you organise Liquid so it stays readable across many templates?

Treat web templates as components, not as pages. The templates people cannot read are the ones where a single page template holds layout, queries, loops and markup for every variation.

• Use one layout web template with blocks, and have page templates extend it and fill named blocks rather than copying the header and footer.
• Move repeated markup into small partial templates and pull them in with include, passing parameters explicitly instead of relying on variables set elsewhere.
• Keep each fetchxml query in one template near where its results are used, name the result variable after what it holds, and never run a query inside a loop.
• Prefix template names by purpose, such as Layout, Partial and Data, so the list in the Portal Management app and the downloaded folder sorts into something navigable.
• Keep business rules out of Liquid where Dataverse can enforce them, because Liquid only shapes what one page shows.
• Comment the intent at the top of each template with a Liquid comment block, which is not sent to the browser.
• Use content snippets for text editors change, so a wording change never needs a template edit.

How do you validate a basic or multistep form before it submits?

Use the hooks the forms already provide rather than intercepting the submit button. Basic forms call a client validation function before they post, and multistep forms have an equivalent for each step. Your form custom JavaScript wraps the original function, runs its own checks, shows a message in the validation summary and returns false to stop the submit.

Client validation is for the user's convenience only. Anyone can bypass it with the browser tools, so every rule that matters must also hold on the server: required columns and business rules on the Dataverse table, a plug-in for anything more complex, and table permissions that limit which records the user can create or change. The permission side is covered in depth in our guide to fixing Power Pages table permissions.

How do you call a Power Automate flow or custom logic securely when a form is submitted?

Never put a flow URL with its signature, an API key or a client secret in JavaScript, a web file or a snippet. Anything the browser can read, any visitor can read and reuse. Use one of the routes where the site authenticates the call and the secret stays on the server.

• Keep credentials for external systems in the flow connection, Dataverse environment variables backed by Azure Key Vault, or the plug-in configuration, never in the site.
• Include the anti-forgery token on every Web API and flow call, using the token helper shown in current Microsoft documentation.
• Return only what the page needs to show, not the full response from the external system.
• Check current Microsoft documentation for what the Power Pages flow trigger passes about the signed-in user and for any limits on flow calls.

How do you put Power Pages code under source control with pac pages download and upload?

Download the site to a folder, commit it, and make changes through that folder rather than in several browser tabs. The Power Platform CLI command pac pages download (formerly pac paportal download) writes the site configuration as files: web templates, content snippets, site settings, web files, and each page's copy, custom JavaScript and custom CSS as separate files beside its YAML. pac pages upload writes changes back, and the --modelVersion option tells the CLI whether the site uses the standard or enhanced data model.

That makes every JavaScript and Liquid change a reviewed commit with a diff, instead of an edit nobody can trace. Build your bundle in the repository and copy the output into the web file's folder before upload. How the CLI, the repository and a pipeline fit together for solutions is on our Power Platform ALM page, and moving a whole site between development, test and production, including deployment profiles and the records that are usually missed, is covered in deploying Power Pages between environments.

• Agree one rule: code is changed in the repository and uploaded, and studio edits are limited to content and layout.
• Download before you start work, because someone may have edited content in the studio since your last upload.
• Never commit secrets, and exclude local build folders from the repository.

How do you stop design studio edits and code changes overwriting each other?

Separate the owners. Most overwrites happen because a developer uploads a folder downloaded last week, replacing a page a content editor changed yesterday, or an editor pastes a fresh copy of a page over script that was in the page copy.

Keep all behaviour in custom JavaScript, form scripts and web files, where editors do not work. Download immediately before upload and review the diff for content changes you did not make. After editing code with Edit code in the studio, use Sync in the design studio so the open session reflects it. And check changes in a development site first, then move them forward, rather than editing production in the studio and trying to reconcile the repository afterwards.

How do you debug Power Pages JavaScript that only fails for some users?

Reproduce as the user, not as an administrator. Scripts often fail only for a signed-in contact with a particular web role, because the list, form or column they expect is hidden by table permissions or the page is not visible to that role.

Sign in to a development site with a test contact in the same web roles, open the browser developer tools, and check the console for errors, the network tab for failed Web API or flow calls and their status codes, and the elements tab for whether the list or form markup exists at all. A Web API call that returns a permissions error is telling you about table permissions or site settings, not about your JavaScript. Check that the web file loaded the version you expect, and clear the cache if it did not.

Should a portal with this much custom code stay on Power Pages?

Usually yes. Custom JavaScript, web files and Liquid are normal Power Pages development, and a well-structured bundle keeps a portal maintainable for years. What a full Power Pages build covers is on our Power Platform consulting page.

The question worth asking is how much of the site is now custom front end with Power Pages underneath. We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. If most screens have become bespoke JavaScript, a React front end over the Dataverse Web API or a custom-built CRM on React, Node.js, PostgreSQL or .NET may be simpler to own, and our Power Pages or custom front end comparison sets out when that switch is justified.

How does Solzet help structure custom JavaScript and Liquid in Power Pages?

We start by downloading the site into a repository and mapping where code currently lives: page copy, custom JavaScript fields, snippets, web files and forms. Then we move behaviour into one shared bundle with page-scoped initialisers, split large templates into readable partials, move secrets and external calls behind the flow trigger or server-side logic, and set up upload through the CLI so every change is reviewed. The portal keeps working throughout, because each page moves on its own.

The work is done by senior consultants and full-stack developers delivering remotely from Yerevan, Armenia, with 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly for your team or white-label for Microsoft partners. Security questions go through our table permissions guide, and slow pages through our Power Pages performance guide.