Episode Details

Sharing business data with external users sounds simple—until you realize you’re exposing your core systems to people outside your organization. Most companies approach this the wrong way. They either lock everything down and slow collaboration, or they open access in ways that create governance risks. The real challenge isn’t sharing data—it’s doing it in a way that is secure, scalable, and aligned with how modern platforms work. That’s exactly where tools like Microsoft Power Pages come into play. They are designed to bridge the gap between internal systems and external users without breaking governance. In this episode, featuring Nicholas Hayduk [MICROSOFT - MVP], we break down how organizations can safely expose data, avoid common pitfalls, and build scalable external experiences on top of Microsoft Dataverse.

 🌐 WHAT POWER PAGES ACTUALLY IS (AND WHAT IT ISN’T)

One of the biggest misconceptions is treating Power Pages like a traditional website builder. It’s not. Power Pages is the external-facing layer of the Microsoft Power Platform. While tools like Power Apps and Power BI are built for internal users, Power Pages is specifically designed for external audiences—customers, partners, or members. At its core, it’s a web portal framework that connects directly to Dataverse. That means:

• Your data lives in Dataverse
• Your logic lives in Dataverse
• Your portal is simply the controlled access layer

This makes it fundamentally different from SharePoint-style content systems. It’s not about pages—it’s about data interaction.

🔐 THE IDENTITY & ACCESS MODEL YOU CAN’T IGNORE

When you open systems to external users, identity becomes the first architectural decision—not an afterthought. Power Pages introduces a flexible authentication model. Users are stored as contacts in Dataverse and can log in using various identity providers like Microsoft accounts, Google, or LinkedIn. But here’s where it gets interesting: the security model is not based on ownership like traditional Dataverse roles. Instead, access is defined through relationships and web roles. This creates a different way of thinking about permissions:

• Access is tied to relationships in data
• Users see records connected to them (e.g., their cases or accounts)
• Security is contextual, not hierarchical

This model is powerful—but also easy to misunderstand if you expect traditional role-based security.

⚙️ THE LICENSING REALITY (AND WHY IT MATTERS)

Power Pages doesn’t follow the typical per-user licensing model used internally. Instead, it’s based on monthly active users. You purchase capacity in packs, and each unique login within a month counts as a user. There’s also a pay-as-you-go option for more flexibility. What makes this important is not just cost—it’s architecture. Your licensing model directly impacts:

• Performance (server capacity scales with users)
• Scalability planning
• Governance of access

If you underestimate usage, your portal won’t break—but it will slow down. And that becomes a user experience issue long before it becomes a licensing issue.

🧱 BUILDING YOUR FIRST PORTAL: WHERE MOST GO WRONG

Starting with Power Pages is not just about spinning up a site—it’s about sequencing your architecture correctly. Most successful implementations follow a pattern:

• First, establish your Dataverse model (often via Dynamics 365)
• Then, layer Power Pages on top
• Finally, design external access and user journeys

A common mistake is treating it like a standalone tool. It isn’t. It depends heavily on Dataverse being structured properly from the start. Another trap is underestimating the skill set required. Power Page