A portal separates what visitors see from what authored pages can query. Pages are the first: path-addressed content with a draft/publish lifecycle. Data views are the second: explicit, per-entity publications that are the authored page layer's only general route to your records. Keeping the two apart is what makes authored exposure auditable — the complete answer to "what general record data can these pages query?" is the list on the Data Views tab, not something buried in page designs. Purpose-built commerce operations, when a portal is bound to a storefront channel, are a separate allowlisted API surface.
This page is intentionally text-only in the current demo2 pass. The tenant's portal registry has no row, so the Pages and Data Views tabs and their create dialogs cannot be reached without creating production configuration. An empty portal register or an unrelated setup table would not evidence these fields; the descriptions below are grounded in the portal detail implementation and should receive visuals only after demo2 contains an approved disposable portal.
Portal pages
A page is addressed by its site-relative path (/, /products, /support/contact) and carries:
- A type. Designed pages are free-form layout documents. Entity list pages embed one published data view as a paged list. Two further types — entity detail and app page embeds — can be authored, but designed pages and entity list embeds are the types that render content on the portal today.
- An audience. Public pages serve anonymous visitors and signed-in users alike; Authenticated pages serve signed-in external users only. An anonymous visitor requesting an authenticated page receives a sign-in requirement, not a not-found — the page's existence is not a secret, its content is.
- A draft and a published snapshot. Edits land in the draft; the portal serves only the snapshot taken at the last Publish draft. The two can differ for as long as you like, which is what lets you rework a live page safely. An unpublished page is invisible to the portal entirely.
- Navigation placement. A sort order positions the page in the menu. If the site has no authored navigation document, the published pages in sort order are the menu.
- SEO metadata. Per-page overrides (title, description) can be recorded on the page for search engines.
The Pages tab makes route, page type, audience, publication state and navigation order reviewable together. Add Page records Label, site-relative Path, Page type, Audience and Order; creating the row does not publish it. Open the new row to add a draft layout or embed target, then use Publish draft only after review.
Data views: the authored page layer's record window
Authored portal pages have no general access to your records. A data view publishes exactly one entity view — the same list views used inside the application, a column set plus a base filter — to one portal, together with:
- An audience, the crucial setting, because it decides whose identity executes the query. Public views always run as the portal's anonymous visitor identity — even when the caller is signed in — so a catalog is identical for every visitor. Authenticated views require a signed-in external user and run as that person, so ownership and record-security rules scope the rows: this is the "my orders" pattern.
- A page size cap — the most rows a single request may return (default 50, up to 250). Visitors page through larger results.
- An active switch — deactivating stops serving immediately without deleting the configuration.
The Data Views tab is the portal's exposure register: it shows the entity and underlying view together with audience, active state and page cap. Publish Data View asks for a readable label, entity, one of that entity's views, audience and page-size cap. The entity and view pair is the data boundary; the audience determines which principal executes it. Review both before choosing Publish.
Exactly what a published view exposes
For any data view, the exposure is computable, not discovered:
- Fields: the columns of the entity view, minus anything field-level security hides from the executing identity.
- Rows: the records matching the view's base filter, intersected with what the executing identity is allowed to read — the anonymous visitor identity for public views, the signed-in user for authenticated ones.
- Volume: at most the page size cap per request.
Everything else is a hard boundary for authored page queries: entities with no published view are unreachable through this surface, drafts and site settings are never served, and the view's filter cannot be widened from the browser — any filter a visitor's request adds is combined with the view's own filter, so it can only narrow the result.
Publishing and the read grant
Publishing a public data view is a security action: it grants read access on that entity to the shared Portal Anonymous security profile carried by the tenant-wide anonymous principal. The grant is managed for you: when the last active public view of an entity, across all of your portals, is deleted or deactivated, the grant is revoked again. Authenticated views need no anonymous grant; they rely on the signed-in user's own access.
Two practical consequences:
- The Data Views tabs of your portals are, together, the organization's complete public general-query exposure list for authored pages. Review any bound commerce channel separately.
- Editing the underlying entity view edits the portal. The view is live configuration, not a snapshot — adding a column or loosening the filter changes what visitors receive on their next request, with no publish step in between. Review view edits with the same care as a publish.
Common questions
Does publishing a data view expose the whole entity?
The read grant is entity-wide for the anonymous profile, but reach is not: visitors can only query through published views, so what they can actually retrieve is the union of your public views' columns and filtered rows, still subject to record and field security. The practical rule stands regardless: publish a view only when every record its filter matches is fine to treat as public.
If I edit the entity view later, does the portal change?
Yes, immediately — the data view references the live entity view. The draft/publish gate covers page layouts, not view definitions. To rework a view a portal is serving, deactivate the data view first, or build the change on a copy of the view and re-point the data view when it is ready (editing a data view lets you switch which view it serves).
Can two portals publish the same entity?
Yes — each portal publishes its own data views, and several can reference the same entity or even the same entity view. The anonymous read grant is shared: it exists while any portal has an active public view of the entity, and is revoked when the last one goes.
Why does a public list look identical to a signed-in user?
By design. Public views always execute as the portal's anonymous identity, so a catalog page is consistent for every visitor — being signed in never changes a public surface. Person-specific data belongs on an Authenticated view, which runs as the caller.