Table of Contents

    External User Access Setup

    Rumman Ansari June 05, 2026 17 views Subject Details

    External User Access Setup

    External User Access Setup in Microsoft Power Pages means configuring how users outside the organization can access a Power Pages website securely. External users may include customers, partners, vendors, clients, applicants, or other non-employee users who need to interact with a business website or portal.

    Microsoft Learn explains that Power Pages can provide access to external audiences and that Power Pages site user information is stored as contact records in Microsoft Dataverse. Before users can authenticate to a Power Pages site with a local account, a record must exist for them in the site's Contacts table. [1](https://learn.microsoft.com/en-us/power-pages/security/external-access)

    In an enterprise environment, external access should always be planned carefully because it can expose business content, Dataverse records, forms, lists, and protected pages to people outside the organization. Internal guidance found in [power pages user guide.pptx](https://ts.accenture.com/sites/MailerPro/KMSTechnology/tauseef/_layouts/15/Doc.aspx?sourcedoc=%7B29811DC9-15B0-40E2-8FE3-C0AD4FBD933A%7D&file=power%20pages%20user%20guide.pptx&action=edit&mobileredirect=true&DefaultItemOpen=1&EntityRepresentationId=b2820060-c776-4af2-b408-2f1fe2db84dc) says that for Power Pages external access, B2B guest access may be allowed in limited instances only, and anonymous sites and users will not be allowed for use at Accenture. [2](https://ts.accenture.com/sites/MailerPro/KMSTechnology/tauseef/_layouts/15/Doc.aspx?sourcedoc=%7B29811DC9-15B0-40E2-8FE3-C0AD4FBD933A%7D&file=power%20pages%20user%20guide.pptx&action=edit&mobileredirect=true&DefaultItemOpen=1)

    External User Access Setup is the process of allowing outside users to access a Power Pages site through planned authentication, contact records, invitations, web roles, page permissions, table permissions, and site visibility controls.

    Why External User Access Setup is Important

    Power Pages is commonly used for customer portals, partner portals, registration websites, application portals, and self-service websites. These scenarios often require people outside the organization to sign in, submit data, view records, or complete business tasks.

    Microsoft Learn explains that the Power Pages site visibility setting controls who can access a website. A private site restricts access to specific people in the organization, while a public site can be accessed by anyone with the link. [3](https://learn.microsoft.com/en-us/power-pages/security/site-visibility)

    Microsoft Learn also states that anyone on the Internet can view public sites anonymously or when authenticated with an identity provider. Public websites are production sites that are fully operational for customers to use. [3](https://learn.microsoft.com/en-us/power-pages/security/site-visibility)

    • External access helps customers, partners, or clients use a website without internal employee access.
    • Authentication confirms the identity of external users before they access protected pages.
    • Web roles control what external users can access after sign-in.
    • Table permissions protect Dataverse records exposed through forms, lists, Liquid, Web API, and other components.
    • Site visibility controls whether a site is private during development or public when ready for external use.

    External User Access Setup Architecture

    External user access in Power Pages can be understood as a layered security model. The user first reaches the site, then authenticates, then maps to a Dataverse contact, then receives web-role-based access, and finally interacts with pages and Dataverse data according to permissions. 

    External User
   |
   v
Power Pages Site
   |
   v
Authentication Provider
   |
   v
Dataverse Contact Record
   |
   v
Web Role Assignment
   |
   v
Page Permissions + Table Permissions
   |
   v
Allowed Pages, Forms, Lists, and Dataverse Records

    Microsoft Learn states that Power Pages site user information is stored as contact records in Dataverse, and that a contact record must exist before users can authenticate with a local account. [1](https://learn.microsoft.com/en-us/power-pages/security/external-access)

    Microsoft Learn also states that Power Pages invitations can assign a contact to an account, assign the contact to one or more roles, and execute a workflow when the contact redeems an invitation. [4](https://learn.microsoft.com/en-us/power-pages/security/invite-contacts)

    Main Components of External User Access

    Component Purpose Power Pages Example
    Site Visibility Controls who can access the website Private during development, public when ready for customer use
    Authentication Provider Controls how users sign in Microsoft Entra External ID or another supported identity provider
    Contact Record Represents the Power Pages site user in Dataverse Customer contact, partner contact, applicant contact
    Invitation Sends a registration link and invitation code to a user Invite a partner user to register for portal access
    Web Role Controls access to protected content and data Customer, Partner, Reviewer, Admin
    Page Permission Controls access to protected pages Restrict dashboard page to signed-in partner users
    Table Permission Controls access to Dataverse records Allow customer users to read their own service requests

    Microsoft Learn explicitly describes site visibility, authenticated users, web roles, table permissions, and page permissions as key parts of Power Pages security.

    Site Visibility for External Access

    Site visibility is one of the first settings to understand before giving access to external users. Microsoft Learn states that all sites created in Power Pages are private by default. [3](https://learn.microsoft.com/en-us/power-pages/security/site-visibility)

    Microsoft Learn explains that only site makers and organization users who the maker granted access to can view private sites. Site visitors need to authenticate with the organization's Microsoft Entra ID identity provider to view private site contents. [3](https://learn.microsoft.com/en-us/power-pages/security/site-visibility)

    Microsoft Learn also explains that when a site is ready to go live, site visibility can be set to public. It also warns makers to be cautious when editing a public site because changes are visible to external users immediately. [3](https://learn.microsoft.com/en-us/power-pages/security/site-visibility)

    Visibility Type Meaning Recommended Learning Use
    Private Site Only makers and selected organization users can view the site Use during development and internal review
    Public Site Anyone with the link can access the site Use only when the site is production-ready and approved

    Authentication for External Users

    Authentication decides how external users prove their identity. Microsoft Learn states that Power Pages can integrate with authentication providers such as Microsoft Entra External ID, Microsoft, and LinkedIn.

    Microsoft Learn’s external access documentation recommends using the Microsoft Entra External ID identity provider for authentication and says the local identity provider is deprecated. [1](https://learn.microsoft.com/en-us/power-pages/security/external-access)

    Microsoft Learn describes Microsoft Entra External ID as a Customer Identity Access Management solution that personalizes and secures customers' and partners' access to websites and applications. [5](https://github.com/MicrosoftDocs/power-pages-docs/blob/main/power-pages-docs/security/authentication/entra-external-id.md)

    Authentication Option Meaning Important Note
    Microsoft Entra External ID Identity provider for customers and partners Microsoft Learn recommends this for Power Pages authentication
    Local Account Username and password stored through Power Pages local authentication Microsoft Learn recommends Microsoft Entra External ID and says local identity provider is deprecated
    Other Identity Providers Supported sign-in providers used for authentication Should be selected based on business and security requirements

    Contact Records for External Users

    External users in Power Pages are represented as contact records in Dataverse. Microsoft Learn states that Power Pages site user information is stored as contact records in Dataverse. [1](https://learn.microsoft.com/en-us/power-pages/security/external-access)

    Microsoft Learn explains that before users can authenticate to a Power Pages site with a local account, a record must exist for them in the site's Contacts table. It also says that contact records created by makers do not have a username and password until a username is entered and the change password workflow is used to set an initial password. [1](https://learn.microsoft.com/en-us/power-pages/security/external-access)

    Contact Record Item Purpose
    Name Identifies the external user as a person or contact.
    Email Address Used for communication and invitation delivery.
    Username Needed when using local account authentication.
    Web Roles Controls what the contact can access on the site.
    Account Relationship Can connect the contact to an account when required by business design.

    Inviting External Users

    Invitations are useful when many users need to be added to a Power Pages site. Microsoft Learn explains that users can register directly by adding a username and password to their contact record, but if many users need to be added, an easier way is to send them an invitation by automated email. [4](https://learn.microsoft.com/en-us/power-pages/security/invite-contacts)

    Microsoft Learn states that the invitation email contains a link to the website and an invitation code that can include granting the user specific roles or privileges. [4](https://learn.microsoft.com/en-us/power-pages/security/invite-contacts)

    Microsoft Learn also states that Power Pages invitations can send a single invitation or invite a group, specify an expiration date, and make the invitation appear to be sent by a specific user or site contact. [4](https://learn.microsoft.com/en-us/power-pages/security/invite-contacts)

    Invitation Capability Meaning
    Single Invitation Invite one external contact to the site.
    Group Invitation Invite multiple contacts when supported by the invitation process.
    Expiration Date Limit how long the invitation can be used.
    Roles or Privileges Grant specific access during invitation redemption.
    Invite Redemption Activity Microsoft Learn states this is created in both the invitation record and contact record when redeemed.

    Web Roles for External Users

    Web roles define what external users can access after authentication. Microsoft Learn explains that web roles allow users to perform special actions or access protected content and data on the site. Web roles link to users, table permissions, and page permissions.

    Microsoft Learn also explains that a web role is basically a collection of permissions to the content of a site. Before authenticated users can access restricted tables or restricted pages, they need to be assigned to a web role.

    External User Type Possible Web Role Example Access
    Customer Customer Submit and view own requests
    Partner Partner Access partner-specific pages and records
    Reviewer External Reviewer Review assigned application records
    Portal Administrator Administrator Access broader administrative pages when allowed

    The role names in this table are teaching examples; the underlying concept is based on Microsoft Learn’s explanation that web roles control protected content and data access.

    Page Permissions and Table Permissions

    External users should not automatically see all pages or all Dataverse records. Page permissions protect pages, while table permissions protect Dataverse data.

    Microsoft Learn states that page permissions associated with web roles can protect content and components on individual pages.

    Microsoft Learn states that access to Dataverse information through lists, forms, Liquid, and the Web API is protected by table permissions. Table permissions are associated with web roles to provide appropriate access to users.

    Microsoft Learn also states that access to Dataverse records is automatically restricted in Power Pages when using forms, lists, Liquid, the Portals Web API, and other components accessing Dataverse tables. To allow access, table permissions must be configured and associated to web roles. [4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)

    Security Layer Controls Example
    Page Permission Which pages can be opened Only partners can open Partner Dashboard
    Table Permission Which Dataverse records can be accessed Customer can read only allowed request records
    Web Role Which user group receives permissions Customer role, Partner role, Reviewer role

    Recommended External User Access Setup Flow

    The following workflow is a teaching-friendly setup flow based on Microsoft Learn’s documented concepts for site visibility, external access, invitations, web roles, page permissions, and table permissions. 

    1. Identify external audience
2. Decide whether the site should remain private or become public
3. Choose authentication strategy
4. Create or prepare Dataverse contact records
5. Invite external contacts when needed
6. Assign web roles
7. Configure page permissions
8. Configure table permissions
9. Test access as each external user type
10. Review governance and production readiness

    Microsoft Learn supports the individual parts of this workflow by documenting site visibility, contact records, invitations, web roles, page permissions, and table permissions. [3](https://learn.microsoft.com/en-us/power-pages/security/site-visibility)[1](https://learn.microsoft.com/en-us/power-pages/security/external-access)[4](https://learn.microsoft.com/en-us/power-pages/security/invite-contacts)[4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)

    External Access Setup Planning Table

    Planning Area Question to Ask Example Decision
    Audience Who needs access? Customers, partners, vendors, clients, applicants
    Site Visibility Should the site be private or public? Private during development; public only when ready
    Authentication How will users sign in? Microsoft Entra External ID or approved identity provider
    Contact Management How will external users be represented? Dataverse contact records
    Invitation Will users self-register or receive invitations? Invitation email with redemption link and code
    Roles What user groups are required? Customer, Partner, Reviewer, Admin
    Data Access Which Dataverse records can each role access? Own records, account-related records, or admin-level records
    Testing Has access been tested from each user role? Test as anonymous, customer, partner, and admin if applicable

    Enterprise Governance Considerations

    In an enterprise environment, external access may require additional governance approval. The internal [power pages user guide.pptx](https://ts.accenture.com/sites/MailerPro/KMSTechnology/tauseef/_layouts/15/Doc.aspx?sourcedoc=%7B29811DC9-15B0-40E2-8FE3-C0AD4FBD933A%7D&file=power%20pages%20user%20guide.pptx&action=edit&mobileredirect=true&DefaultItemOpen=1&EntityRepresentationId=b2820060-c776-4af2-b408-2f1fe2db84dc) says a Power Pages request should include the business need, the type of audience, whether users are Accenture, Avanade, or AFS employees, the total number of users, site name, site URL, site template, and AIR ID. [2](https://ts.accenture.com/sites/MailerPro/KMSTechnology/tauseef/_layouts/15/Doc.aspx?sourcedoc=%7B29811DC9-15B0-40E2-8FE3-C0AD4FBD933A%7D&file=power%20pages%20user%20guide.pptx&action=edit&mobileredirect=true&DefaultItemOpen=1)

    The same internal guide states that for external access, B2B guest access may be allowed in limited instances only, and anonymous sites and users will not be allowed for use at Accenture. [2](https://ts.accenture.com/sites/MailerPro/KMSTechnology/tauseef/_layouts/15/Doc.aspx?sourcedoc=%7B29811DC9-15B0-40E2-8FE3-C0AD4FBD933A%7D&file=power%20pages%20user%20guide.pptx&action=edit&mobileredirect=true&DefaultItemOpen=1)

    [Power Intake_Team Handbook_v2.docx](https://ts.accenture.com/sites/CIOOperationsLeadershipSite/FY27%20Planning/_layouts/15/Doc.aspx?sourcedoc=%7B00E6CB36-6C9B-4A96-A5BF-68ABFFA80ABE%7D&file=Power%20Intake_Team%20Handbook_v2.docx&action=default&mobileredirect=true&DefaultItemOpen=1&EntityRepresentationId=237fc6ee-d4f1-4c0d-8815-2700e58ba265) says that Power Pages requests should be evaluated based on business need, and it lists decision guidance such as recommending Canvas Apps for internal Accenture users or access only, rejecting external users or access outside approved B2B scenarios, and rejecting Proof of Concept scenarios as not allowed at Accenture. [6](https://ts.accenture.com/sites/CIOOperationsLeadershipSite/FY27%20Planning/_layouts/15/Doc.aspx?sourcedoc=%7B00E6CB36-6C9B-4A96-A5BF-68ABFFA80ABE%7D&file=Power%20Intake_Team%20Handbook_v2.docx&action=default&mobileredirect=true&DefaultItemOpen=1)

    Governance Area Why It Matters
    Business Need Explains why Power Pages is required instead of another option.
    Audience Type Clarifies whether users are internal or external.
    External Access Scenario Helps determine whether the scenario fits approved external access patterns.
    AIR ID Internal guide says AIR ID is required for provisioning dedicated environments.
    Anonymous Access Internal guide says anonymous sites and users will not be allowed for Accenture use.

    Example: Partner Portal External Access

    A partner portal may allow partner users to sign in, view partner-specific information, submit forms, and view records that are allowed by table permissions. 

    Partner User
   |
   v
Signs in through approved identity provider
   |
   v
Mapped to Dataverse Contact
   |
   v
Assigned Partner Web Role
   |
   v
Accesses Partner Dashboard Page
   |
   v
Views or submits Dataverse records based on table permissions
    Setup Item Partner Portal Example
    External Audience Partner users
    Authentication Approved external identity provider
    Contact Record Partner contact in Dataverse
    Web Role Partner
    Page Permission Restrict Partner Dashboard to Partner role
    Table Permission Allow access only to approved partner-related Dataverse records

    This example is a teaching scenario based on Microsoft Learn’s documented concepts: authenticated users, contact records, web roles, page permissions, and table permissions. [1](https://learn.microsoft.com/en-us/power-pages/security/external-access)[4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)

    Example: Customer Self-Service Portal

    A customer self-service portal may allow customers to sign in, submit support requests, and view their own request records if permissions are configured correctly. 

    Customer
   |
   v
Sign in
   |
   v
Customer Contact Record
   |
   v
Customer Web Role
   |
   v
Submit Request Form
   |
   v
View My Requests List
    Portal Component External Access Requirement
    Submit Request Form Create permission for the correct Dataverse table
    My Requests List Read permission for records the customer is allowed to view
    Request Details Page Page permission and table permission for protected details
    Customer Web Role Assigned to customer contacts after registration or invitation

    This example is based on Microsoft Learn’s explanation that table permissions protect Dataverse information through lists, forms, Liquid, and the Web API, and that table permissions are associated with web roles to provide access.

    External User Access Setup Checklist

    Checklist Item Status
    External audience identified To be completed
    Business need documented To be completed
    Site visibility reviewed To be completed
    Authentication provider selected To be completed
    Contact records prepared To be completed
    Invitation strategy selected To be completed
    Web roles created To be completed
    Page permissions configured To be completed
    Table permissions configured To be completed
    External user testing completed To be completed
    Governance approval reviewed if required To be completed

    Best Practices for External User Access Setup

    • Keep the site private while it is being developed and tested.
    • Use public visibility only when the site is production-ready and approved.
    • Use Microsoft Entra External ID when it fits the external-user authentication requirement.
    • Create clear web roles for each external audience type.
    • Use page permissions to protect pages that should not be public.
    • Use table permissions to protect Dataverse data exposed through forms, lists, Liquid, and Web API.
    • Use invitations when external users need a controlled registration process.
    • Test the site using each external role before launch.
    • Document which user type can access which page, form, list, and Dataverse table.
    • Follow organizational governance rules for external and anonymous access.

    These recommendations are based on Microsoft Learn’s documented guidance for site visibility, external access, invitations, web roles, page permissions, and table permissions, along with enterprise guidance from [power pages user guide.pptx](https://ts.accenture.com/sites/MailerPro/KMSTechnology/tauseef/_layouts/15/Doc.aspx?sourcedoc=%7B29811DC9-15B0-40E2-8FE3-C0AD4FBD933A%7D&file=power%20pages%20user%20guide.pptx&action=edit&mobileredirect=true&DefaultItemOpen=1&EntityRepresentationId=b2820060-c776-4af2-b408-2f1fe2db84dc). [3](https://learn.microsoft.com/en-us/power-pages/security/site-visibility)[1](https://learn.microsoft.com/en-us/power-pages/security/external-access)[4](https://learn.microsoft.com/en-us/power-pages/security/invite-contacts)[4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)[2](https://ts.accenture.com/sites/MailerPro/KMSTechnology/tauseef/_layouts/15/Doc.aspx?sourcedoc=%7B29811DC9-15B0-40E2-8FE3-C0AD4FBD933A%7D&file=power%20pages%20user%20guide.pptx&action=edit&mobileredirect=true&DefaultItemOpen=1)

    Common Mistakes Beginners Make

    • Making a site public before testing authentication and permissions.
    • Assuming external users can access the site without proper contact records or identity setup.
    • Creating web roles but forgetting to assign them to contacts.
    • Protecting pages but forgetting Dataverse table permissions.
    • Configuring table permissions but not associating them with web roles.
    • Allowing too much access through broad permissions.
    • Not testing the experience from an external user perspective.
    • Ignoring organizational governance rules for external or anonymous access.

    These are teaching cautions based on Microsoft Learn’s explanation that site access, authentication, contact records, web roles, page permissions, and table permissions are separate parts of Power Pages security. [3](https://learn.microsoft.com/en-us/power-pages/security/site-visibility)[1](https://learn.microsoft.com/en-us/power-pages/security/external-access)[4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)

    External User Access Setup Terms to Remember

    Term Simple Meaning
    External User A user outside the organization who needs access to a Power Pages site.
    Site Visibility A setting that controls whether the site is private or public.
    Authentication Provider The system used to sign in and verify users.
    Microsoft Entra External ID A Customer Identity Access Management solution for customers and partners.
    Contact Record The Dataverse record that represents a Power Pages site user.
    Invitation An email-based process that lets a contact redeem access to the site.
    Web Role A role that controls access to protected content and data.
    Page Permission A rule that protects individual pages or page components.
    Table Permission A rule that protects Dataverse records accessed through Power Pages.

    These terms are based on Microsoft Learn documentation for Power Pages site visibility, external access, invitations, authentication, web roles, page permissions, and table permissions. [3](https://learn.microsoft.com/en-us/power-pages/security/site-visibility)[1](https://learn.microsoft.com/en-us/power-pages/security/external-access)[4](https://learn.microsoft.com/en-us/power-pages/security/invite-contacts)[4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)

    Important Points to Remember

    • All Power Pages sites are private by default.
    • Private sites are visible only to site makers and organization users granted access by the maker.
    • Public sites can be accessed by anyone with the link.
    • Power Pages site user information is stored as contact records in Dataverse.
    • Microsoft Learn recommends Microsoft Entra External ID for authentication and says the local identity provider is deprecated.
    • Power Pages invitations can include roles or privileges and can create invite redemption activity when redeemed.
    • Web roles connect users with page permissions and table permissions.
    • Table permissions are required to allow access to Dataverse records through forms, lists, Liquid, Web API, and other components.
    • Enterprise guidance in [power pages user guide.pptx](https://ts.accenture.com/sites/MailerPro/KMSTechnology/tauseef/_layouts/15/Doc.aspx?sourcedoc=%7B29811DC9-15B0-40E2-8FE3-C0AD4FBD933A%7D&file=power%20pages%20user%20guide.pptx&action=edit&mobileredirect=true&DefaultItemOpen=1&EntityRepresentationId=b2820060-c776-4af2-b408-2f1fe2db84dc) says anonymous sites and users will not be allowed for use at Accenture.

    These points summarize Microsoft Learn and internal enterprise guidance for external user access setup. [3](https://learn.microsoft.com/en-us/power-pages/security/site-visibility)[1](https://learn.microsoft.com/en-us/power-pages/security/external-access)[4](https://learn.microsoft.com/en-us/power-pages/security/invite-contacts)[4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)[2](https://ts.accenture.com/sites/MailerPro/KMSTechnology/tauseef/_layouts/15/Doc.aspx?sourcedoc=%7B29811DC9-15B0-40E2-8FE3-C0AD4FBD933A%7D&file=power%20pages%20user%20guide.pptx&action=edit&mobileredirect=true&DefaultItemOpen=1)

    Simple Summary

    External User Access Setup in Power Pages is about giving outside users controlled and secure access to a business website. The setup usually includes site visibility, authentication, Dataverse contact records, invitations, web roles, page permissions, and table permissions.

    Microsoft Learn explains that Power Pages site user information is stored as contact records in Dataverse, and that invitations can be used to register users and assign roles or privileges. [1](https://learn.microsoft.com/en-us/power-pages/security/external-access)[4](https://learn.microsoft.com/en-us/power-pages/security/invite-contacts)

    For enterprise use, external access should be reviewed carefully. Internal guidance found in [power pages user guide.pptx](https://ts.accenture.com/sites/MailerPro/KMSTechnology/tauseef/_layouts/15/Doc.aspx?sourcedoc=%7B29811DC9-15B0-40E2-8FE3-C0AD4FBD933A%7D&file=power%20pages%20user%20guide.pptx&action=edit&mobileredirect=true&DefaultItemOpen=1&EntityRepresentationId=b2820060-c776-4af2-b408-2f1fe2db84dc) says that B2B guest access may be allowed in limited instances only and that anonymous sites and users will not be allowed for use at Accenture. [2](https://ts.accenture.com/sites/MailerPro/KMSTechnology/tauseef/_layouts/15/Doc.aspx?sourcedoc=%7B29811DC9-15B0-40E2-8FE3-C0AD4FBD933A%7D&file=power%20pages%20user%20guide.pptx&action=edit&mobileredirect=true&DefaultItemOpen=1)

    Conclusion

    External User Access Setup is a critical Power Pages topic because most real business portals are designed for users outside the organization. A Power Pages site may look complete with pages, forms, and lists, but it is not ready for external users until authentication, roles, permissions, and governance are properly planned.

    The safest approach is to identify the external audience first, choose the right authentication strategy, represent users as Dataverse contacts, assign proper web roles, protect pages with page permissions, protect Dataverse records with table permissions, and test access from each user role before launch.

    After learning this topic, learners can move to Power Pages Security & Table Permissions, where they can understand how to protect Dataverse records, restrict data by user role, and design secure external-facing portals.

    Microsoft Power Platform Mastery