Building Customer Portals with Power Pages + Dataverse

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.


Get full access to M365 Show - Microsoft 365 Digital Workplace
Daily at m365.show/subscribe