Portal complaints have a useful property: the serving rules are strict, so the causes are enumerable. A portal serves only a published, active site; only published, active pages whose audience admits the caller; and only active data views, executed as a real identity. This page works through the four complaints that cover most cases, with the checks in the order they pay off.
This page stays text-led because each symptom maps to several distinct admin and visitor states; a single portal screenshot would imply one diagnosis. Follow the named register, tab and state checks below, then capture the exact failing surface for the incident record.
Start every portal incident in the registry. Confirm the site exists, then compare Name, Slug and Address, Published, Status, Anonymous, Pages and Version. If no row exists, the hostname cannot legitimately serve a tenant portal; creating a replacement before locating the intended record risks duplicate configuration and conflicting host registration rather than repairing the original.
Work outward in serving order: domain and certificate, active published portal, requested page path and audience, published version, active data view, executing visitor identity, and underlying permissions. For signup, also check both enablement switches, invitation delivery and duplicate identity rules. Capture the hostname, path, visitor state, expected version, timestamp and response, but redact customer records and authentication artifacts from broad support screenshots.
The portal doesn't load at all
Work down the list and stop when the behavior explains itself:
- The site isn't published. On Setup → Portals the site shows Draft, and its detail header offers Publish rather than Unpublish. An unpublished site is not served at all.
- The site is inactive. The Active switch is the kill switch — it beats publish state, so a published-but-inactive site still serves nothing.
- Anonymous access is off. With Anonymous visitors off, anonymous requests get not-found; the portal exists only for signed-in external users.
- The Portals module is disabled for the organization — every portal serves not-found while it is off.
- You published moments ago. Hostname registration is picked up on the next lookup, and misses are cached briefly — retry after a minute before digging deeper.
A page is missing from the portal
- It isn't published. The Pages tab shows each page's state — Published, Draft or Empty — and only published pages exist to visitors.
- It is inactive. An inactive page is skipped even when published.
- Its audience is Authenticated and the visitor is anonymous: the page is absent from the anonymous menu, and a direct visit to its path asks for sign-in rather than rendering.
- The authored navigation omits it. When the site carries a navigation document, that document is the menu — a page can be live but unlinked. Check by visiting its path directly.
A page renders but is empty
- The published snapshot is empty. The page was published while its draft had no content; publishing snapshots whatever the draft holds. Add the content and Publish draft again.
- Edits were made but never published. The portal serves the snapshot, not the draft — this is the single most common "my change isn't showing" cause.
- An embed page names no data view (or misnames one) in its embed target.
- The page type has no portal rendering yet. Designed pages and entity list embeds are the types that render content today; entity detail and app page embed types can be authored ahead of their portal rendering and come up empty.
A data list shows no rows or an error
- "Portal is not ready to serve data." The portal's visitor identity has not been provisioned yet. Open the portal in Setup and save it once — provisioning is retried on save — then reload the portal.
- The data view is inactive or was deleted. Deactivation stops serving immediately.
- The view's filter matches nothing. Open the same entity view inside the application and confirm it returns rows there before suspecting the portal.
- Record security excludes the rows for the executing identity. What you see inside the application as an internal user is not the reference: public views execute as the portal's anonymous identity, authenticated views as the signed-in visitor, and each is scoped by its own access. The layers are laid out in How portal security works.
Signup does nothing
- Signup is disabled on the site. The Self-service signup switch must be on, and the site must be published.
- The address already has an account. By design the visitor still sees the same "check your email" acknowledgement, but no new mail is sent for an existing account — the right move is to sign in with it.
- The invite email hasn't arrived yet. Invites are sent in the background — allow a few minutes and check the spam folder. The email asks the person to set a password; until that step completes, the account cannot sign in.
Common questions
The portal shows data we never meant to publish — where do I look?
The union of active public data views across all of the organization's portals is the complete general-query exposure for authored pages, so check every portal's Data Views tab, not just the one you were editing. Then look at the shared Portal Anonymous security profile for grants an administrator added by hand — those apply to every anonymous visitor and are not removed automatically. Deactivating a data view stops it serving immediately. If the portal is bound to a commerce channel, review its separately allowlisted catalog and transaction configuration as a second surface.
I fixed the page but the portal still shows the old version.
Saving edits the draft; the portal serves the published snapshot — use Publish draft on the page after editing. Site settings (theme, navigation, description) are the exception: those apply to a live portal on save.
Everything is green in Setup but the custom domain returns not-found.
Domains route; publishing serves. Confirm the domain row on Setup → Domains shows Verified, then confirm the site itself is published and active — a verified domain in front of an unpublished site returns not-found. The DNS-side checks are in Publishing, hostnames and custom domains.