Power Pages Consulting: External Portals, Security First
Everything else in the Power Platform faces your employees. Power Pages faces everyone else — customers, vendors, applicants, partners. That one difference changes the engineering: an internal app that overshares embarrasses you in a meeting; a portal that overshares is an incident with outside witnesses.
So our Power Pages practice leads with the part most portal projects bolt on at the end. Security isn't a phase before launch. It's the product.
What organizations build portals for
Customer self-service.
Order and case status, document access, standard requests — handled at the front door instead of in a shared inbox.
Vendor and supplier portals.
Onboarding, document submission, insurance and compliance uploads, status visibility — with each vendor seeing exactly their own records and nothing else.
Intake and applications.
Permits, registrations, grant applications, warranty claims — structured forms feeding a real process instead of a PDF feeding a retyping job.
Partner collaboration.
Authenticated portals where partners work shared pipelines or programs without being inside your tenant.
Public information with structured data behind it.
Searchable directories, program catalogs, status boards — content backed by governed data rather than hand-edited pages.
The common shape: an external audience, structured data in Dataverse, and a business process behind the form. That shape is exactly what Power Pages is for — and what generic website builders quietly can't do.
Security is the product
Here's the sentence that should be on every Power Pages proposal and usually isn't: a portal is a door from the public internet into your business data. Power Pages is built for that job — but only if its security model is configured deliberately.
What deliberate looks like:
- Authentication designed, not defaulted. Who signs in, with what identity — external identity providers, invitation-only partner access, or anonymous access as an explicit, justified decision rather than a leftover setting.
- Default-deny data access. Table permissions and web roles built so external users see nothing until a rule grants it — the burden of proof on access, not on restriction.
- Least-privilege records. A vendor sees their submissions, a customer sees their cases. Row-level thinking, verified with tests, not assumed from a diagram.
- Tested like an outsider. Before launch we attempt to reach what shouldn't be reachable — because on the internet, someone eventually will.
- Monitored after launch. Sign-ins, failures, and unusual access patterns watched by someone with a name, per the Ø Standard.
If a proposal you're evaluating doesn't talk about table permissions, ask why. It's the entire game.
Portals → Pages migration
If you're running a legacy Dynamics 365 Portal or "Power Apps Portals" site, you're on the platform's past. Microsoft consolidated that lineage into Power Pages — same Dataverse foundation, new design studio, modern templates, and current security tooling — and legacy portals are the kind of aging estate that gets riskier quietly.
The migration conversation covers three options, not one:
Migrate
when the portal earns its keep: move to Power Pages, modernize the design, and use the migration as the excuse to re-audit permissions and retire accumulated cruft rather than lifting it.
Rebuild
when the old portal grew by accretion: sometimes the requirements have drifted so far that a clean Pages build against today's process beats archaeology.
Retire
when usage data says nobody would miss it. We check before we migrate — moving an unused portal is perfectly billable and completely pointless, which is why we won't propose it.
The stack behind the portal
A portal is the front door; the work happens behind it. Submissions route through Power Automate approvals and integrations. Staff work the queue in internal Power Apps. The data lives governed in Dataverse, where internal security rules keep applying. And increasingly, portals host Copilot Studio agents so external users get answers before they open tickets — with the tighter grounding and guardrails external agents demand.
We build the whole corridor, not just the door — one team, one security model, no seam between the portal and the process behind it.
When Power Pages isn't the answer
- A marketing website. Brochure sites belong on a CMS. Power Pages earns its licensing when there's data and process behind the pages, not headlines in front of them.
- Internal-only tools. If everyone signing in works for you, build a Power App — simpler, cheaper, better fit.
- Consumer software at scale. A product with consumer-grade UX ambitions and very large user volumes is custom-development territory, and we'll say so.
- A simple form. One intake form with light needs may just be Microsoft Forms feeding a flow. Not every door needs a building around it.
If the license math doesn't justify the portal, you'll hear it from us first.
How an engagement works
The IMP0WER GRID, applied to portals. Gauge: who the external audience is, what data they touch, what the current portal (if any) actually gets used for, and where the security gaps are — estate-wide, this rides with the Power Platform Health & Governance Gauge. Route: the authentication model, data and permission architecture, and licensing position in plain English — decided before anything is styled. Install: build against the Ø Standard, with security testing as a launch gate, not a follow-up. Distribute: monitoring, content ownership, and a support path — because an unowned portal on the public internet is not a risk we'll leave behind.
A founder leads every engagement, extended by the IMP0WER delivery team. We've been building on Microsoft platforms since 2008, and portals are where that experience earns its keep: the failure modes are quiet, external, and cheaper to prevent than to explain.
Frequently asked questions
Is Power Pages the same as Power Apps Portals?
Power Pages is the successor — Microsoft consolidated Dynamics 365 Portals and Power Apps Portals into it. Same Dataverse foundation, new tooling and security surfaces. If you're on the legacy lineage, a migrate/rebuild/retire review is due; the middle of this page covers how we run it.
What does Power Pages licensing look like?
It's capacity-based, priced around monthly authenticated and anonymous users rather than per-seat licenses. The practical consequence: audience size and authentication design drive cost, which is one more reason those decisions come first. We'll model your scenario in real numbers during an engagement, and our recommendations are never driven by license quotas, so the model isn't shaped by a sales target.
Can external users see our internal data?
Only what table permissions and web roles explicitly grant — which is exactly why we build them default-deny and test them from the outside before launch. The platform enforces what you configure. The discipline is configuring it deliberately and proving it.
Can a portal include an AI agent?
Yes — Copilot Studio agents embed in Power Pages, and external-facing agents are held to harder requirements: authentication, tighter grounding, stricter guardrails, closer monitoring. A good second project once the portal's permission model has proven itself; a risky first one.
Can it match our brand?
Yes. Templates and the design studio cover most needs; custom code covers the rest. The trade, plainly: heavy customization is buildable, but every custom layer is something your team maintains later — sometimes the better answer is a cleaner design that ships and survives.
We inherited a portal nobody owns. Where do we start?
With a usage and permission review — what it exposes, who actually uses it, what breaks if it goes away. Then migrate, rebuild, or retire, deliberately. An orphaned external portal fails the Ø Standard twice over: no owner, public door. That review is worth scheduling this quarter, not eventually.