A portal is an external-facing website built on your organization's data and published straight from Setup: a customer self-service portal, a product catalog, a partner site. Its visitors are not members of your organization — they are anonymous members of the public and signed-in external users — and the portal is served on its own hostname, entirely outside the application your teams sign in to. This page explains the two ideas every portal task builds on: what a portal is made of, and the publishing model that decides what visitors can see.
What a portal is made of
A portal (Setup → Feature Hub → Portals → Portals) is three kinds of configuration:
- The site — the portal's identity and chrome: a label, a slug (the hostname label the portal is served under), theme tokens, header navigation, and switches for anonymous access and self-service signup.
- Pages — path-addressed content (
/,/products,/support): free-form designed pages, and pages that embed a published data view as a list. Each page declares its audience — public, or signed-in visitors only. - Data views — the only general record-query window available to authored portal pages. Each one publishes a single entity view (a column set plus a filter) to the portal; an authored page cannot query an entity for which the portal has no published view. A portal bound to a commerce channel can also use the storefront's purpose-built catalog, cart, checkout and account operations; those are allowlisted workflows rather than access to the general data interface. See Portal pages and data views.
One organization can run several portals side by side — each with its own slug, pages, data views and theme. The Portals registry lists them with Name, Slug, Address, Published, Status, Anonymous, Pages and Version columns — the complete inventory of external sites your organization serves, so treat every row as security-relevant. The neighbouring Domains and Portal Settings entries hold custom hostnames and organization-wide portal controls. Create a portal only after naming its owner, audience, hostname and data-exposure purpose; author pages in draft, review each data view before publishing it, test as an anonymous and as a signed-in visitor, and only then publish.
The publishing model
Nothing on a portal is public by accident. Three gates stand between authoring and a visitor's browser, and each is an explicit action:
- The site is published. An unpublished or deactivated site is not served at all.
- Each page is published. Page edits accumulate in a draft; publishing snapshots the draft as the served version. An unpublished page is invisible to the portal, and later edits change nothing until you publish again.
- Each data view is published. Publishing a data view is what grants the portal read access to that entity — and the grant is withdrawn automatically when the last active view of the entity is removed. The full scoping model is in How portal security works.
Retracting mirrors publishing at every level: unpublish a page and it disappears from the portal; unpublish the site and it stops serving immediately. Nothing is deleted by retracting, so a portal can go dark and come back without rework.
What's in this section
| Page | What it covers |
|---|---|
| Build and publish a portal | The end-to-end procedure: site, pages, data views, publish, verify |
| Portal pages and data views | Page types and audiences, and exactly what data a published view exposes |
| Publishing, hostnames and custom domains | Publish and retract, the platform hostname, and serving on your own domain |
| Portal visitors, signup and identity | Anonymous visitors, self-service signup, and what signed-in portal users are |
| How portal security works | The scoping model, and how it composes with your organization's security |
| Troubleshooting portals | Grounded checks for not-found errors, missing pages, empty lists and signup |
Who can build portals
Building portals is an administrator activity: the Setup screens require the portal-management capability (setup.portals.manage), and the Portals module must be enabled for your organization. Visitors need nothing — no account for public pages, and an external account (self-created through signup, or invited) for signed-in areas.