Power Pages developer in Melbourne

Why Power Pages

If your staff already work in Dynamics 365 or a Dataverse app, Power Pages lets customers, members or suppliers see and update the same data without a separate database and a sync job in between. An application, a booking, a change of details or a case goes straight into Dataverse, where your team picks it up.

It's a good fit when the data lives in Dataverse anyway and the portal is mostly forms, lists and records. It's a worse fit for a marketing site or a highly custom public web app. I'll tell you on the first call which one you've got.

What goes into a build

Sign-in

Who signs in, and how, gets decided first. Staff, members and the public often need different identity providers, and getting this wrong late is expensive. Contacts in Dataverse get linked to the right sign-in so people only ever see their own records.

Table permissions and web roles

This is where most of the risk is. Table permissions decide which records a signed-in or anonymous user can read, create or change. Set them too wide and a portal can expose data it was never meant to. I set them as narrowly as the process allows, scoped to the contact or account, and test them as each type of user before go-live.

Microsoft is previewing a new model where Dataverse checks these permissions itself. Before switching a site over, read what to check before opting in to Power Pages enhanced authorisation.

Forms and lists

Basic and multistep forms on Dataverse tables, with validation that matches the rules in your model-driven app, so data from the portal is as clean as data entered by staff. Where a form needs more than configuration, I add Liquid templates, JavaScript and the Power Pages Web API.

Processing behind the portal

What happens after someone hits submit: plugins in C# for rules that must run inside the save, Power Automate for follow-up steps and notifications, and Azure Functions when the portal needs to talk to a finance or payment system.

Deployment

The site is kept in a solution and source control and moves between environments through a pipeline using the PAC CLI. No rebuilding pages by hand in production, and no wondering which version is live.

Common Power Pages problems

• Permissions wider than they need to be. Often added in a hurry to make something work during testing, then never tightened.
• Forms that fail on real data. They work for the person who built them and break on a missing lookup, a long name or a second browser tab.
• Slow pages. Usually a list or Liquid query pulling far more records than it shows.
• Manual deployments. Changes made directly in the live site, so test and production drift apart.
• Licensing surprises. Power Pages is licensed by monthly authenticated and anonymous users. Worth estimating before the build starts, not after go-live.

Part of the wider Dynamics picture

A portal is rarely the whole project. It usually sits next to a model-driven app, some flows and an integration or two. I've worked on Dynamics and Dataverse for more than 16 years, so I can build the portal and the parts behind it without handing off between specialists. See also Power Platform consulting and Dynamics 365 CE work.

Inherited a portal and not sure what it exposes? Table permissions get a careful look in every Dynamics 365 and Power Platform health check.