When designing a Power Pages (formerly Power Apps Portals) website, one of the most crucial aspects is deciding which pages should be public and which should be private. This is fundamental for security, user experience, and business logic. Whether you’re building a customer portal, partner site, or internal system, correctly managing page visibility ensures that only the right audience sees the right content.
This guide explores private vs public pages, how to configure them, and best practices for secure and effective portal design.
What Are Public and Private Pages?
Public Pages
These are accessible to any user, including those not signed in (anonymous users). No authentication is required.
Examples:
- Homepage
- About Us
- Contact page
- Product listings
- Support articles
Private Pages
These are accessible only to authenticated users who have been granted access through Web Roles. You must sign in to view these pages.
Examples:
- User dashboard
- Order history
- Admin panel
- Membership-only content
- Employee resources
How to Create Public Pages in Power Pages
- Open Design Studio or Portal Management App
- Create a Web Page using the editor.
- Under Permissions or Page Permissions, make sure:
- No Web Role is assigned
- Or a Web Role with anonymous access is associated (like “Anonymous Users”)
- Save and publish the page.
The page will now be visible to anyone visiting the portal, even without signing in.
🔹 By default, all new pages are public unless protected by a Web Role.
How to Create Private Pages in Power Pages
- Create the Web Page using Power Pages Design Studio or Portal Management App.
- Navigate to Page Permissions or click “Control access”.
- Enable Enable Table Permissions or Access control.
- Add the Web Role(s) that should have access (e.g., “Authenticated Users”, “Manager”, “Admin”).
- Save and publish the page.
Access Control Levels:
| Option | What It Does |
|---|---|
| Grant access to authenticated users | Requires login, but allows any signed-in user |
| Grant access to specific Web Roles | Only users with selected roles can access |
| Grant access to anonymous users | Makes the page public again |
Example Scenarios
Public Page: Product Catalog
- Audience: Visitors, search engines
- Visibility: Open to all
- Web Roles: None or “Anonymous Users”
- Security: No authentication required
Private Page: Order Management Dashboard
- Audience: Logged-in customers
- Visibility: Requires sign-in
- Web Roles: “Registered Customers”
- Security: Protected with Web Role + optionally Table Permissions
Making Nested Pages Private/Public
Child pages inherit the access settings of their parent page unless explicitly changed.
Example:
- If the parent “Admin” page is private and assigned to the “Admin” Web Role:
- All child pages (e.g., “Reports”, “User Management”) will be private too.
- You can override this by changing access settings on the child page.
Tips for Managing Page Access Effectively
- Plan Access Structure Early: Decide which parts of the portal are public and private during the wireframing stage.
- Use Descriptive Web Roles: Name roles clearly – “Customer”, “Manager”, “Partner”, etc.
- Avoid Mixing Roles in One Page: Keep content logically separated by access levels.
- Use Redirects: If a user tries to access a private page without proper permissions, redirect them to a login or access-denied page.
- Use Conditional Content: On shared pages, use Liquid or JavaScript to hide/show content based on login status or role.
- Always Test as Different Users: Confirm access by logging in as users with different Web Roles.
Switching Between Public and Private
You can convert a public page to private (or vice versa) any time by modifying the Web Role access.
To switch a public page to private:
- Add Page Permissions.
- Assign a Web Role.
- Save.
To switch a private page to public:
- Remove all Page Permissions or assign to “Anonymous Users”.
Security Note
Protecting the page isn’t enough – always protect the data too. Even if a page is private, if you expose a form or list, make sure the Table Permissions are properly scoped to prevent unauthorized access to Dataverse records.
Summary Table
| Feature | Public Page | Private Page |
|---|---|---|
| Visibility | Open to all users | Requires login |
| Security | No Web Role needed | Web Role(s) must be assigned |
| Use Case | Info pages, marketing | User dashboards, admin panels |
| Example Web Role | Anonymous Users | Registered User, Admin |
| Setup Complexity | Simple | Needs role and permission setup |
| Search Engine Access | Yes | No (unless indexed by mistake) |
Final Thoughts
Creating public and private pages is a foundational aspect of building secure, user-focused portals in Power Pages. It’s more than just controlling visibility—it’s about guiding users through a structured, intentional experience while protecting sensitive data and workflows.
By understanding and properly configuring Web Roles, Page Permissions, and Table Permissions, you can confidently control access and deliver a seamless, secure experience to every visitor.