Launching a Power Pages Self-Service Channel in 90 Days When Sales Has Already Promised It

What has to be cut to launch Power Pages in 90 days?

Almost everything that was implied in the sales conversation. Ninety days is enough for a solid first release of a self-service channel, and not enough for a portal that does everything customers might want. The fixed date and the fixed budget are not negotiable, so scope is the only variable left. Agree the cut in writing in week 1, with whoever made the promise in the room, and treat every later addition as a trade for something already in scope.

Before committing to the date, confirm Power Pages is the right route at all. Our comparison of Power Pages, guest accounts and a custom front end covers that decision; this page assumes it has been made.

What does the week by week plan look like?

The order matters more than the exact weeks. Each phase removes a risk the next phase would otherwise inherit, and the two phases teams most want to skip, permissions and load checking, are the ones that decide whether the launch survives its first busy week.

Why must environments and ALM be ready in week 1?

Because every change after week 1 has to reach test and production somehow, and a portal assembled by hand in one environment cannot be promoted safely at the end. Put the site and its Dataverse components in a solution from the first day, set up the pipeline, and prove it with a trivial change before any real build starts. Environment variables and connection references for the integration belong in that first week too, so development values never reach production.

The command level detail, from exporting and unpacking solutions to deployment settings files and pipelines, is in our guide to moving Power Platform ALM from manual ZIP files to PAC CLI and pipelines. For a fixed date launch the point is simpler: a late ALM setup costs the weeks you do not have, and hand-made production fixes during hypercare become the defects of release two.

Why must table permissions and web roles come before page design?

Because they decide which rows every list, form, Liquid query and Web API call can return, and retrofitting them onto finished pages means reworking those pages. Teams that design pages first typically make lists "work" with broad permissions and plan to tighten them later. Later is UAT, where tightening breaks pages, and the temptation is to ship the broad version.

In weeks 2 and 3, write the permission matrix: for each audience, each web role, each table, the access type (Contact, Account, Parent, Self or Global) and the privileges. Keep customer data off the built-in Authenticated Users and Anonymous Users roles. Then test it on bare pages with contacts from two different accounts before design begins. What goes wrong when this is skipped, and how to contain it, is set out in our Power Pages table permissions data leak guide.

How do you choose the one journey and the one integration?

Choose the journey that fulfils the promise sales actually made, stated as a customer outcome, not as a list of pages. If the promise was "customers can see where their request is", the journey is sign in, submit or find a request, see its status and add information. For a service portal that journey sits on the case process in Dynamics 365 Customer Service, and it is only as good as the queues, statuses and notifications behind it.

• The journey should be completable end to end without a phone call; a portal that ends with "we will contact you" is not self-service.
• The integration is the one without which the journey is false, for example an order status held in another system; everything else can be linked to, not integrated.
• Define the integration contract early: which data, which direction, how fresh, and what the portal shows when the other system is unavailable.
• Prefer reading integrated data into Dataverse over live calls from the page when freshness allows, since it keeps page response times under your control.
• Write the case or request statuses the customer will see in plain language, and map internal statuses onto them.

How do you check the portal holds up at the concurrency sales promised?

Turn the promise into numbers first: how many customers will be invited, what share will sign in during the launch week or a deadline, and how many will attempt the critical flow at the same time. A launch email to the whole customer base, a renewal date or a regulatory deadline can bring a large part of it in on the same morning.

By week 8, test the critical flow, not the home page, at that concurrency in a non production site with production-like data volumes, and follow Microsoft's current guidance for load testing Power Pages before you run it. Look at page response times, the Dataverse queries behind lists, plug-ins and flows triggered on submit, and the integration under load.

• Lists that filter or sort on columns without a sensible view design get slower as data grows.
• Synchronous plug-ins or real-time workflows on submit add their time to every customer's wait.
• Flows behind the form run asynchronously; decide what the customer sees while they run.
• Live calls to the integrated system inherit that system's limits and outages.
• If the numbers do not hold, stagger invitations or change the design in week 8, not on launch day.

How is Power Pages licensed, and why does it surprise teams at UAT?

Power Pages is licensed per website per month by capacity: authenticated users, counted as unique people who sign in to that site in the month, and anonymous users, counted as unique visitors who use the site without signing in. Capacity is bought as prepaid capacity packs or paid as you go through an Azure subscription, and internal users who already hold qualifying Power Apps or Dynamics 365 licences generally do not consume it. We do not quote prices, and Microsoft revises definitions and minimums, so check current Microsoft licensing before you budget.

The surprise arrives at UAT when someone finally multiplies the invited customer base by the sign-in pattern the promise implies. Build the volume model in weeks 2 and 3: expected monthly unique sign-ins per site, the peak month, anonymous traffic on pages that read Dataverse, and how many sites you will run. More on how capacity scales with audience size is in the portal route comparison.

What kills a 90-day Power Pages launch?

The failures are predictable, which is why they are avoidable. Each one below moves a hard problem to the end of the plan, where it meets the fixed date.

What should hypercare cover in the last fortnight?

Hypercare is planned work, not the time left over. Set it up before launch so the first two weeks of real customers produce fixes and evidence rather than noise.

• A daily triage with the product owner, the build team and service desk lead, reviewing portal errors, failed flows and customer contacts about the portal.
• Monitoring in place before launch: flow run failures alerted to a named owner, integration errors visible, and site telemetry if you have configured it.
• Fixes released through the pipeline, never edited directly in production.
• A watch on sign-in and registration problems, which are the most visible failures to customers.
• Actual monthly authenticated users tracked against the licensing volume model.
• A dated handover to the team that will support the portal, with the runbook and the release two backlog.

When is Power Pages the wrong choice for a fixed-date promise?

When the promise describes a product experience rather than a service journey, when the audience model makes Microsoft licensing uneconomic, or when the data the journey needs does not live in, and cannot reasonably be brought into, Dataverse. In those cases a 90-day Power Pages plan meets the date by missing the point.

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. Where Microsoft licensing does not fit the audience, a custom-built CRM and portal on React, Node.js, PostgreSQL or .NET can be scoped to the same fixed date, with its own trade offs in hosting and long term ownership.

How does Solzet deliver a fixed-date Power Pages launch?

We start with a short scoping workshop that produces the written scope cut, the permission matrix outline, the licensing volume model and the week by week plan, and we say plainly if the date cannot be met with the scope on the table. Then our senior consultants and full-stack developers build in the order of this page, with the pipeline running from week 1, a load check by week 8 and hypercare planned before launch.

The full scope of our Power Pages work, from identity and Liquid to PCF controls in portal forms, is described in our Power Platform development service. Solzet delivers remotely from Yerevan, Armenia, with 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly or white-label for Microsoft partners.