Ever shared Dataverse data through email attachments or spreadsheets—only to wake up at 2am wondering who might have access? There’s a better, safer way that won’t make your CISO sweat, and yes, it’s built into Power Platform already. Want to know how to give partners and customers just the access they need, nothing more?
Today we’re building a customer portal with Power Pages—step by step—showing you how to keep your data secure, permissioned, and controlled, all while looking like a true extension of your own brand. Let’s fix the ‘just share it’ problem, for good.
Why Internal Apps Aren’t Enough: The Portal Dilemma
If you’ve ever rolled out a Power App that became the star of your internal team, you know the next question isn’t far behind. Just when you think you’ve nailed the workflow—approval processes humming, dashboards up-to-date—someone from sales, maybe even the CFO, leans in and says, “Can our customers use this too?” That single question often grinds a smooth project to a halt, transforming a tidy internal solution into a can of worms you can’t just seal shut again.
Here’s the reality for most organizations leaning on Dataverse: your team has years of customer data, structured processes, and even some automation humming quietly in the background. But the minute you need to actually show any of that to someone outside your physical office or VPN, things get messy. You know, that sinking feeling when marketing wants to create an onboarding portal for new partners, or support suggests a ticketing portal for vendor issues. Of course, copying data and emailing spreadsheets takes five minutes. Fifteen minutes later, though, you’re trying to track who sent what, to whom, and where it ended up. The moment data leaves Dataverse or your app, your grip on privacy and compliance loosens.
And it isn’t just theoretical risk. We’ve all heard the stories—one too many, honestly—like the finance manager who exported a batch of invoice records for a vendor and, thanks to a wonky Excel filter, ended up attaching every customer’s info instead. Suddenly your CFO’s inbox has half the company’s sensitive data sitting one accidental forward away from a competitor. If you ask a Chief Information Security Officer about the most anxiety-inducing phrase in a project, it’s probably “I just sent them the file—it seemed easier.”
Now, that ease of internal sharing is deceptive. Internal Power Apps are quick wins because everyone’s part of your tenant, inheriting permissions, authentication, and policy controls without any heavy lifting. Internal users sign in, and their access is governed by tried-and-true security groups or roles you already manage. Compliance audits are routine. Data stays inside the blast walls of your identity provider. But the second you want to reach outside—open a door for a customer, a partner, or even a vendor with a custom login—every layer of security, compliance, visibility, and even branding gets complicated.
See, Power Pages was Microsoft’s answer to requests for secure, external-facing portals built on top of Dataverse. But let’s be honest—most people who see the “add external users” option in Power Pages don’t realize what’s under the hood. Clicking through that wizard gives you a working website, but making it actually safe for production, keeping sensitive records hidden from prying eyes, and ensuring users only see what they’re supposed to? That’s not just an optional step—it’s a project in itself.
And yet, plenty still find themselves on the wrong side of this boundary. There’s a recurring pattern: someone spins up Power Pages in a hurry, goes through the default steps, tests a few records, and it all looks fine. But then, a vendor logs in, and they’re staring at other customers’ orders or internal notes that shouldn’t be exposed. The fallout isn’t just a privacy incident; it’s lost trust, support tickets piling up, and sometimes even compliance breaches that have regulatory implications, especially for finance, healthcare, or any business bound by industry rules.
The core challenge isn’t just “Can we display our Dataverse data externally?” It’s “How do we show the right data, to the right people, with the right look, without compromising on security or compliance?” The difference between emailing a report and building a real portal is more than just technology—it’s about building guardrails no one notices until something goes wrong. You can’t rely on good intentions or quick fixes. Once you switch from all-internal to external access, mistakes multiply fast.
Let’s not gloss over branding, either. External portals are the face of your company—customers, vendors, or partners will judge your whole operation by the login page design, password reset flow, and whether the site “feels legit.” Anything sloppy, or that feels cobbled together, equals lost confidence. But getting branding right isn’t just a matter of a logo. Consistency with your internal identity, fonts, colors, emails—all of it reinforces that this isn’t just a side project, but a real extension of your brand promise.
So the recurring question, whether you’re the admin or the project owner, isn’t just about feasibility. It’s about control. Is there a way to let customers, partners, or vendors interact directly with Dataverse data, but still fit it inside your security, privacy, and brand envelope? The answer is a qualified yes—Power Pages paired with Dataverse, when configured with intention, covers all these bases. The catch? There’s a sequence of technical and business steps that you need to nail—because skipping just one can put you right back in spreadsheet-chaos territory.
So, how do you hook up Power Pages to Dataverse, surface the right data, and avoid the nightmare scenarios? The actual connection is simple. What makes or breaks your portal is the sequence of decisions you make from the first click. Let’s look at how to get that foundation right—connecting your portal to Dataverse securely and sidestepping the common pitfalls that trip up so many first-time builders.
Connecting Power Pages to Dataverse—The Secure Way
Let’s say your customer portal project lands on your desk. Power Pages is live, Dataverse holds the gold, and you’re ready to start plugging in tables to show off tickets, invoices, contract lists, or whatever data makes your users’ work easier. At first glance, this part feels like it should be the easiest win of the whole project. If you’ve used Power Apps before, it’s not a leap—go to the Data workspace in Power Pages Studio, click “Add table,” pick the ones you need from Dataverse, and they just appear as options for forms and lists on your new website. It’s painless. You can pull in the Contacts table, the Cases table, or even custom tables your team built last quarter. With a few clicks, you hit Publish and, technically, the portal now “just works.” That’s how most demo videos pitch it.
Right here is where a lot of folks step on a rake. Because behind those three clicks, Power Pages quietly wires up permissions, access points, and sometimes leaves far more open than you expect—especially if you move fast or stick with defaults. By default, when you add Dataverse tables, Power Pages may grant site-wide or global permissions to newly added tables, depending on which options you pick. In particular, some of those tables might even be accessible to anonymous users if you don’t immediately lock things down. This isn’t always obvious, because the Studio lists all the tables, but doesn’t throw up a giant warning about who can see what until you dig into the settings.
The risks aren’t hypothetical. There are incidents—real “oh no” moments—that start with an admin spinning up a test portal, pulling in the Employee table for a fast demo, and forgetting to remove it before that portal gets handed off for production. It’s not just lab data, either. One global services firm published their portal without realizing their internal HR table—complete with salary bands and contact info—was still exposed to authenticated external users, because the default web role permissions were set too broadly. That fix took a weekend, a conference call with legal, and a frantic review of audit logs to reassure the business they didn’t just cause a data breach. Nobody wants to explain that to their CISO.
When you work with internal Power Apps, you can almost rely on the Azure AD bubble wrapping everything. Users get mapped security roles, and unless you grant explicit access, nothing happens outside those lines. Power Pages operates on a different plane. External users are managed as Contacts in Dataverse, and “web roles” drive what they can see and do—totally separate from your internal security roles and groups. The difference is subtle but huge: you need to decide table-by-table, row-by-row, and sometimes field-by-field just what should be visible to those logging in from outside your corporate firewall.
The first time you connect a table, you’ll see Power Pages prompting you to pick which tables to surface. This is your first checkpoint. Do you really need to show the entire Case history, or just open Cases for each user? Should that custom Payments table be visible at all, or does it include sensitive payment instructions that only finance staff should see? If you choose “enable table for anonymous access,” you’re opening that data up to anyone who finds the URL—so unless it’s a public knowledge base, double-check and untick that option.
Web roles form the backbone of your permission model, even at this early stage. By default, Power Pages offers some out-of-the-box web roles—Authenticated User, Anonymous User, and Admin. Don’t assume these mean the same thing as their equivalents in the rest of Microsoft 365. For example, the “Authenticated User” web role is generic and comes with minimal restrictions unless you add your own layers. Failing to assign custom web roles for customers, vendors, or partners can result in all authenticated users sharing the same, overly broad level of access.
Table permissions are where the nitty-gritty starts. Each table you connect should trigger a review—who needs to see this? Should they be able to create, update, or only read? And do they need access to all records, or just their own? This is not the time to sprint. Instead, walk through the Dataverse permission grid with your actual user stories in mind, not just what’s easy to set up. A rush at this stage leads to awkward emails down the line when someone stumbles on info that was never theirs to see.
We’ve seen more than one project get a quick win demo, only to get mired in cleanup after launch. Locking down data after it’s already live is much harder than starting tight and opening up by exception. You don’t want your first bug report to be, “I can see another company’s records—should I be able to?” A little extra effort when first connecting tables—reading every permission, confirming web roles, checking for anonymous settings—pays for itself in calm nights and silent audit logs.
Bottom line, wiring up Power Pages to Dataverse feels easy enough for anyone to do on a Friday afternoon. But if you rely on the defaults or skim past those web role prompts, you’re setting up for a weekend of frantic patching. Treat it like a checklist at preflight: review each table, look at which roles really need what access, and be stingy with permissions until you’re sure. That’s the difference between “it works” and “it’s secure.”
Of course, even the tightest permission controls crumble if you don’t know who’s logging in. Setting up data access correctly is table stakes—but authentication, our next stop, is where the real decisions about access begin.
Authentication: Picking the Right Door for Your Portal
If the front door to your portal isn’t locked, it doesn’t really matter how much time you spent on permissions in Dataverse—anyone who walks up can try the handle. So, the next piece you have to get right is authentication. This doesn’t just decide who can get past the portal’s welcome mat, but also shapes your customer’s first impression. Power Pages gives you a handful of authentication options right out of the box. You’ve got Azure AD B2C, which is kind of the Swiss army knife for customer-facing Microsoft cloud apps. There’s also local authentication, which covers the classic email-and-password flow. And, if your users run their lives through Google or Facebook, you can wire up external identity providers for social logins. It sounds straightforward until you have to actually pick one—and then the questions start flooding in.
It’s not uncommon to see teams get stuck here. The stakes feel high, and there’s no “undo” button if you launch the portal and suddenly realize your customers can’t log in. Maybe you choose local accounts, and then discover half your users never receive welcome emails thanks to an overzealous spam filter. Or you take the plunge with Azure AD B2C, burn a few weekends setting it up, then realize you have no idea how to add Google sign-in without breaking password resets. Sometimes, the confusion goes even deeper—someone tries to use Azure AD (not B2C), which is great for employees, but external customers either get locked out or their authentication isn’t checked at all. Security reviews don’t go well when nobody can say for sure how access is being enforced.
It can go sideways even after launch. There’s a case I remember where a regional insurance company finally finished building their claims portal, went live, and the helpdesk lit up immediately. Customers were seeing endless “invalid login” screens. Turns out, their authentication was set up for Azure AD, requiring work accounts their customers didn’t have. The fix involved pulling everything back offline, setting up B2C, and having hundreds of users re-register—all while fielding calls like, “Why can’t I log in to my own claims?” Now, imagine the opposite problem: someone enables anonymous access during testing, forgets to turn it off, and suddenly anyone with the portal link can see sensitive forms. Nobody wants to run that fire drill, especially when external regulators start asking questions.
So, which method really fits? Azure AD B2C is Microsoft’s go-to answer for customer-facing scenarios and makes sense if you want to handle large numbers of users, support social logins, or offer self-service password resets. B2C gives plenty of flexibility—users can sign in with corporate credentials, Gmail, or Apple ID, set up MFA, and handle password management without your admin team resetting passwords over the phone. But it’s not a magic bullet. For small, low-volume portals, hooking up B2C can feel like rolling out an entire Active Directory just for a handful of logins, introducing complexity you might not need. Local authentication, on the other hand, is fast to deploy, especially if you only expect a few dozen partners or vendors to use the site. But then you’re on the hook for onboarding, password resets, and, depending on your region, security disclosures for breaches.
External identity providers open up the door to Google and Facebook logins—sometimes a requirement for a certain type of customer or market. Social login can boost adoption rates, since nobody likes to remember yet another password, but then you’re juggling multiple flows for password reset, account linking, and, for regulated industries, figuring out if social logins pass your compliance audits. If your portal deals with healthcare, financial data, or anything Europe-related, GDPR and similar data privacy laws add another layer. Not all social login providers keep your data in regions you expect, and privacy policies can change fast. Double check that your authentication provider supports region-specific data centers and audit trails.
Branding is the silent deal-breaker. You can have flawless authentication, but if your login page screams “default Microsoft blue,” customers notice. Power Pages lets you customize the sign-in experience, but only to an extent—some providers give more room to match your company’s look and feel. Pay attention to the “forgot password” and MFA screens, too. Customers who run into a generic, plain-text password reset page are less likely to trust it’s still your company behind the curtain.
Authentication, in the end, is as much about trust and usability as it is about technical enforcement. Choosing the right flow affects how smooth onboarding is for customers, how much time support spends resetting passwords, and whether your audit logs clearly tell you who did what and when. You want to stop the wrong people without making the right users regret signing up. There’s no best answer for every case, just a series of tradeoffs that depend on your audience, your brand, your compliance obligations, and how much complexity you’re willing to support.
If you take the time to map out who needs access, how they’re going to get it, and how you’ll support them as users—not just accounts—you’ll sidestep both the broken login headaches and the compliance nightmares. Once you’ve got a solid authentication method, you’ll know exactly who’s coming through your virtual door. Now the next challenge is making sure that, once inside, users only see the specific information meant for them.
Web Roles and Table Permissions: The Art of Not Oversharing
If you’ve ever logged into a customer portal and accidentally seen another company’s invoice, you know how quickly things go from convenient to uncomfortable. The reality is, this happens far more than most organizations like to admit. All it takes is a single misconfigured permission or the wrong default web role, and suddenly Customer A is seeing Customer B’s support tickets, contract files, or even payments—none of which was intended. The fallout isn’t just a stern email; it often snowballs into angry phone calls, trust issues, and extra scrutiny from compliance teams. Data sharing gone wrong has a way of sticking around.
This is where web roles and table permissions in Power Pages come in. Think of them as the hidden scaffolding that decides what each user can see and do once they’re in. Internal apps lean on security roles in Azure AD—you’ve got a pretty clean mapping between users, groups, and what they should access. But with Power Pages, you’re in a different ballgame. External users aren’t inside your usual directory. Instead, they’re tracked as Contacts in Dataverse, and their rights come from what we call web roles. It sounds dry, but this distinction is at the heart of building a secure portal. Miss it, and you end up playing cleanup for months.
Let’s get into the nuts and bolts. Web roles are assigned to external users when they register or get invited to your portal. These roles group your users by purpose—think “Customer,” “Partner,” “Vendor.” Once you figure out what those buckets are, you map out exactly what each needs to see and do. If your business processes are clear, designing web roles becomes much less of a guessing game. You don’t want your partners poking into customer invoices, and vendors definitely shouldn’t be seeing your client ticket lists. If that sounds obvious, watch what happens when companies skip this step and run “everyone gets the same default role.” It’s an open door nobody meant to prop.
Table permissions are the next key part. When you wire up a Dataverse table to your Power Pages site, you need to decide not just whether the table is visible, but how much of it should be open to each role. This is where scopes come in—global, contact, or account. Global scope is a blunt tool; it lets users see every record in that table. It’s fine for public data like company locations, but dangerous for anything confidential. Account scope narrows access so a user sees only records related to their parent account—a must for B2B portals. Contact scope is the tightest, showing users only records linked to their own contact ID. For customer support scenarios or ticketing, this is where you want to start. Letting users see only their own support cases, for example, keeps privacy intact and email inboxes free of panicked messages about data leaks.
But row-level security is where the real work happens. Power Pages lets you design granular permissions that control not just which tables are visible, but which records and even which fields within those records. So, if a partner needs to update delivery statuses on their own shipments but shouldn’t see detail on anyone else’s orders, you’re covered. Setting this up takes patience—mapping relationships, logic, and business rules—but it pays off when your portal sits quietly in the background, never the source of a privacy scare.
Of course, exceptions pop up. Maybe a support supervisor needs to see every ticket for an entire account, not just their own. Or a finance lead gets broader billing visibility. It’s tempting to just assign them global access and call it a day. Resist that. Instead, create additional web roles for these scenarios—“Partner Manager” versus “Partner User,” for example—and apply permissions carefully. Review these exceptional roles at regular intervals, especially after organizational changes, so nobody keeps outdated access just because “it was easier at the time.” This habit prevents privilege creep and the uncomfortable call from your compliance officer when they audit the system next quarter.
Now, because web roles and table permissions sit outside your usual security roles, it’s easy for responsibilities to get lost. One team sets up the portal. Another manages user onboarding. A third updates data models. If nobody owns the full picture, gaps form. It helps to document every web role, what tables they should see, and why—with real world examples tied to your business process. This simple practice makes onboarding new portal admins smoother, and stops the cycle of re-learning every time the team changes.
Designing roles and permissions as an afterthought is the most common pitfall I see. People focus on the “happy path”—getting any user in, seeing any data. But reality brings edge cases. Occasionally, a portal goes live with global access mistakenly enabled. A partner logs in, and suddenly they’re looking at another vendor’s shipment dates or customer contact info. The incident turns into a fire drill no one wants. Avoid it by pressure-testing your web roles before launch—log in as each type of user, try to break your own assumptions, and confirm row-level visibility is doing its job.
When web roles and table permissions are aligned with actual business needs, the difference is immediate. Customers see only their data. Partners operate in their own workspace. Vendors can check order statuses, but not read your partner lists. Your admins get fewer panicked emails, and the support team isn’t chasing down mysterious visibility bugs in production. The portal feels trustworthy—for both you and your users—because it actually is.
So, what separates a secure, future-proof portal from one you’re always worried about? It’s not slick design or bold promises. It’s a clear, deliberate design for access control—and keeping that model documented and fresh as your business grows.
Conclusion
Building a portal with Power Pages and Dataverse isn’t just about opening up data. It’s making sure your customers or partners only see what they should—and that you can sleep without wondering what’s drifted out of sight. The right structure up front pays off as your business grows or audits come around. Use those web roles and permissions to control access, not just tick a box. If you’re looking to get more value out of Dataverse, these steps are where you start. Let us know what portal headaches you’re wrestling with, and make sure you’re subscribed for more practical guides.
Share this post