Portal pages and data views

Portal pages are the addresses visitors open on a portal, and data views are the published entity views those pages use to show your records. You manage both on a portal's detail page in Setup, after you create the portal and before you publish it. Pages control what is shown and where. Data views control which records the portal can read and as whom. Keeping the two apart makes exposure auditable: a portal's Data Views tab is the complete list of what its authored pages can query.

Overview

Each portal has its own pages and data views. Both are listed on Setup → Feature Hub → Portals → Portals → the portal, on the Pages and Data Views tabs. The detail page also has a General tab (site settings, covered in Portals) and a Members tab (who can sign in, covered in Portal visitors and signup).

• A page has a path such as /, /products or /support/contact, a page type, an audience and a place in the menu. Its layout has a draft and a published version. Visitors only ever see the published one.
• A data view publishes one entity view (the same list views you use inside the application, made of a column set and a base filter) to one portal. Its audience decides whose identity runs the query. A Public data view also gives the shared Portal Anonymous security profile read access to the entity.

A portal bound to a commerce storefront or a learning portal also has its own built-in screens. Those are separate, fixed workflows. They are not served through pages or data views.

When to use it

• Add a page for every address the portal should answer, such as a home page, a catalogue page or a "my orders" page.
• Publish a data view whenever a page needs to show records: a public catalogue (Public) or a signed-in member's own records (Authenticated).
• Use the page and data-view switches to take one page or one list offline without unpublishing the whole portal.

How xMatix handles it

What a visitor gets for a path

When someone opens a portal address, xMatix serves the page at that path only if all of these are true:

1. The portal is published and Active, and the Portals module is enabled.
2. The portal allows anonymous visitors, or the visitor is signed in and counts as signed in on this portal. External users count only on portals they are a member of. Staff users of your organization always count.
3. A page with exactly that path exists and has been published.
4. The page's audience is Public, or the visitor counts as signed in.

An anonymous visitor who opens an Authenticated page is sent to the portal's sign-in screen and returned to the page afterwards. A signed-in visitor who is not a member of this portal sees "This page is not available for your account." Any other address returns the portal's not-found page.

There is one exception. When a portal is bound to a commerce storefront or a learning portal and no published page exists at /, the home address shows the storefront or the learner experience. If you publish a page at /, it replaces that home screen.

What a page shows

The portal renders a page in this order:

1. If the page has a published layout, the layout is shown, whatever the page type.
2. Otherwise, if the page type is Entity list embed and its Embed target names a data view, that data view is shown as a paged table.
3. Otherwise the page shows "Page label has no published content yet."

Entity detail embed and App page embed can be selected and saved, but the portal does not render their embed target. Such a page shows only its published layout, if it has one.

A layout is a JSON document in the same layout format the application uses for record pages. On a portal, it is rendered read-only and can use these building blocks: grids, form layouts, spacing, tabs, collapsible panels, cards, statistics, read-only field displays (text, number, select, switch, checkbox, date and preview text), the portal data list widget, which shows a published data view, and the portal learning widget. Other application widgets are not available on a portal.

What a data view exposes

For any data view, the exposure can be worked out from its settings:

• Rows: the records that match the entity view's base filter, limited to what the executing identity may read. A Public view always runs as the shared anonymous visitor, even when the caller is signed in, so every visitor sees the same list. An Authenticated view runs as the signed-in visitor, so their security profile, record ownership and record-security rules decide the rows. That is the "my orders" pattern.
• Fields: the entity view's columns, minus anything field-level security hides from the executing identity.
• Volume: at most the Page size cap per request. Visitors page through larger results.

A visitor's request cannot widen any of this. A filter or search sent with the request is combined with the view's own filter, so it can only narrow the result. Entities with no published view, unpublished drafts and site settings are never served through this route.

The anonymous read grant

Publishing an active Public data view gives the Portal Anonymous security profile Read and View All access on that entity. xMatix manages this grant for you. It stays while at least one active Public data view of the entity exists on any of your portals. When you deactivate or delete the last one, the grant is withdrawn. Only the access xMatix added is removed: anything an administrator added to that profile by hand stays. Authenticated data views never use this grant. See How portal security works.

What is live and what waits for publishing

Only a page's layout has a draft and a published version. Everything else takes effect on the live portal as soon as you save it:

• the page's Label, Path, Page type, Audience, Order, Embed target and SEO;
• a data view's View, Audience, Page size cap and active state;
• the entity view itself. A data view points to the live entity view rather than a copy. If you add a column or loosen the view's filter, visitors see the change on their next request.

Prerequisites

• The Manage portals capability on your security profile, and the Portals module enabled for your organization (Setup → Feature Hub → Portals → Settings).
• A portal created on Setup → Feature Hub → Portals → Portals. See Build and publish a portal.
• For data views, the entity views you want to publish already exist, with the columns and base filter you intend to expose. Entity views are maintained on Setup → Design Studio → Entities → the entity → Experience. See The data model.

Procedure

Step 1 — Open the portal's pages

Open Setup → Feature Hub → Portals → Portals and click the portal's name. Select the Pages tab. The table lists every page with its Path, Type, Audience (Public or Signed-in), Published state and Order.

Step 2 — Add a page

Click Add Page. Enter a Label (the menu text) and a Path, for example / for the home page or /products. Choose the Page type and Audience, and adjust Order if needed (it defaults to the number of pages already on the portal). Click Create. The page appears with Published set to Empty. It is not visible on the portal yet.

Step 3 — Publish a data view

Select the Data Views tab and click Publish Data View. Enter a Label, choose the Entity, then one of that entity's views in View. Choose the Audience and, if needed, change the Page size cap (default 50, maximum 250). Click Publish. The data view is listed as Active and is served immediately. If the audience is Public, the anonymous read grant on the entity is added at the same moment.

Step 4 — Give the page content

On Pages, click the page's name (or Edit in its row). Expand Content (JSON): draft layout, embed target, SEO:

• For a designed page, enter the layout JSON in Draft layout. To show a data view inside the layout, use the portal data list widget and give it the data view's name, plus an optional title and page size.
• For an Entity list embed page, leave Draft layout empty and enter the data view's name in Embed target, for example {"dataView": "retailer-hub-c-products", "title": "Our range"}. See How do I find a data view's name?
• In SEO, you can set the browser title and search description, for example {"title": "Products", "description": "Our current range"}. Without an SEO title, the page label is used.

Click Save. The Published column shows Draft for a page that has a draft layout and has never been published. The embed target and SEO already apply to the live page if it is published.

Step 5 — Publish the page

Click Publish draft in the page's row. The current draft layout becomes the published layout, the page shows Published, and the portal's version number goes up. To publish later edits to the layout, click Publish draft again. Publishing copies whatever the draft holds at that moment, including an empty draft.

Step 6 — Check it as a visitor

Open the portal's address (shown in the page header) in a private browser window. Open the page, check the menu, and page through any list. For an Authenticated page, sign in with an external account that is a member of this portal.

Step 7 — Take a page offline or remove it

• Unpublish in the page's row removes the published layout. The address returns not-found at once. The draft is kept, so you can publish it again later. No confirmation is asked.
• Delete in the page's row asks for confirmation, then removes the page and its draft permanently.

Step 8 — Change, pause or remove a data view

• Edit lets you change the Label, switch to another View of the same entity, change the Audience and the Page size cap. The entity cannot be changed: publish a new data view instead.
• Activate / deactivate stops or resumes serving without deleting the configuration. Deactivating the last active Public view of an entity withdraws the anonymous read grant.
• Delete asks for confirmation, stops serving immediately, and withdraws the anonymous read grant if this was the last active public view of the entity.

To change a data view from Public to Authenticated, deactivate it first, then edit the audience, then activate it again. Editing the audience directly does not withdraw the anonymous read grant (see Business rules).

Fields

Add Page and Edit Page

Pages table

Publish Data View and Edit Data View

The Data Views table also shows Status (Active or Inactive).

Business rules

• Path uniqueness. Two pages on one portal cannot share a path. The same path can exist on different portals.
• Only the layout is versioned. Publish draft copies the draft layout to the published layout and records the publish time. Every other page and data-view setting is live as soon as it is saved.
• Authoring needs the module. Adding a page and publishing a page are refused while Enable Portals is off. Editing, unpublishing and deleting are still possible, so you can take content down.
• Menu. If the portal's Navigation document (on the General tab, under Advanced) lists header items, those items are the menu. Otherwise the menu is every published page the visitor can see, by Order. Authenticated pages appear in that automatic menu only for signed-in visitors.
• Data view names are fixed. A data view's name is generated once, when it is published, from the portal's internal name and the data view's label. Renaming the label later does not change it. If the name is already taken, -2, -3 and so on are added.
• Grant follows active public views. Creating or activating a Public data view adds the anonymous read grant. Deactivating or deleting one withdraws it if no other active Public view of the entity remains on any portal. Changing the audience from Public to Authenticated in Edit does not withdraw the grant, and neither does deleting a whole portal. Deactivate the view first in both cases.
• Portal list rendering. A data list shows up to six columns: the first six fields the view returns, skipping record ids and lookup id fields. Column headings are generated from field system names, not their labels.
• Rate limits. The portal limits how often one visitor can query data views. A visitor who exceeds the limit is asked to wait and try again.

Example

A distributor runs a portal called Retailer Hub for its retailers.

1. On Data Views, the administrator publishes Products (an Item view that lists active items, audience Public, page size cap 25) and My orders (an Order view, audience Authenticated users only, page size cap 50).
2. On Pages, they add Home at / (Designed page, Public, order 0), Products at /products (Entity list embed, Public, order 1) and My orders at /my-orders (Entity list embed, Authenticated users only, order 2).
3. They edit Products and set Embed target to {"dataView": "retailer-hub-c-products", "title": "Our range"}, then do the same for My orders with retailer-hub-c-my-orders. They paste the home page layout into Draft layout on Home.
4. They click Publish draft on all three pages, then Publish on the portal.
5. In a private window, an anonymous visitor sees Home and Products in the menu, and 25 items per page on Products. Opening /my-orders takes them to the sign-in screen. After a retailer who is a member signs in, My orders appears in the menu and lists only the orders that retailer's own record security allows.

Training

Practice exercise

In a sandbox portal:

1. Publish a Public data view on a harmless entity view, with Page size cap 5.
2. Add an Entity list embed page at /practice, set its Embed target to that data view's name, and click Publish draft.
3. Publish the portal if it is not published yet, then open /practice in a private window.

Expected result: a table of at most five rows per page, with at most six columns. Now deactivate the data view and reload: the page shows a warning that the data view failed (404). Activate it again and the list returns.

Quick reference

• Pages and data views: Setup → Feature Hub → Portals → Portals → the portal → Pages / Data Views.
• Only the draft layout waits for Publish draft. Path, audience, embed target, SEO and every data-view setting are live on save.
• Entity list embed + {"dataView": "<name>"} in Embed target = a paged table.
• Entity detail and app page embeds render nothing beyond a published layout.
• Public data view = shared anonymous identity + entity-wide read grant. Authenticated = the signed-in visitor's own access.
• Editing an entity view changes every portal that serves it, immediately.
• Public → Authenticated: deactivate, edit, activate.
• A page at / replaces a storefront or learning home screen.

Permissions

Without Manage portals, the Portals entry is hidden and the portal screens refuse access. Capabilities are granted per security profile; see Security profiles.

Configuration

Common problems

The page says "has no published content yet"

The page has no published layout and is not an Entity list embed with an Embed target. Either add the layout and click Publish draft again (it was probably published while the draft was empty), or set the page type and embed target. Entity detail and app page embeds always need a layout.

A list shows "Data view failed (404)"

The name in the embed target or widget does not match an active data view on this portal. Check that the data view is Active and that the name is exactly right, including any -c or -2 part. For a portal created moments ago, the portal's visitor identity may not be ready: save the portal once on General and retry.

A list shows "Data view failed (401)"

The data view's audience is Authenticated users only and the visitor is not signed in as a member of this portal. Put such lists on Authenticated pages, or use a Public data view.

A list shows "Data view failed (429)"

The visitor sent too many data requests in a short time. Waiting a moment and reloading clears it.

Visitors still see my old layout

You saved the draft but did not publish it. Click Publish draft. The Published column does not show pending edits, so publish after every layout change you want live.

Visitors saw a change I had not published

Only the layout is versioned. A change to the path, audience, embed target, SEO, a data view or the underlying entity view applies immediately. Deactivate the data view or unpublish the page while you rework it.

The list columns are not the ones I expected

The portal list shows up to six fields of the view, skipping ids and lookup id fields, with headings made from field system names. To control what is shown, put the fields you want first in the entity view, or build a designed page layout around the data list widget.

"A page with this path already exists on the site."

Another page on this portal uses that path. Change one of them, or delete the unused page.

"A valid site-relative path is required."

The path is empty, longer than 400 characters, or contains //, .., ? or #.

"Draft layout is not valid JSON." (or "Target …", "SEO …")

The text in that box is not valid JSON. Fix the syntax, or clear the box to remove the setting.

"The Portals module is disabled for this organization."

Enable Portals is off at Setup → Feature Hub → Portals → Settings. Adding and publishing pages is refused until it is switched on.

My signed-in customer sees "This page is not available for your account."

They have an account in your organization but are not a member of this portal. Add them on the portal's Members tab.

Common questions

Does publishing a data view expose the whole entity?

The grant is entity-wide for the anonymous profile, but what visitors can reach is not. A visitor can only query through published views, so they can retrieve the columns and filtered rows of your public views, still subject to record and field security. Publish a Public view only when every record its filter matches is fine to treat as public. Remember that a later change to the entity view's filter changes what is public, without any publish step.

If I edit the entity view later, does the portal change?

Yes, immediately. The data view points to the live entity view. To rework a view safely, copy it, change the copy, and then use Edit on the data view to switch its View to the copy when it is ready. Alternatively, deactivate the data view while you work.

How do I find a data view's name?

The setup screen does not display it. It is generated when the data view is published from the portal's internal name and the data view's Label, joined and lowercased, with every run of other characters turned into one hyphen. A portal created with the label "Retailer Hub" has the internal name retailer-hub_c, so a data view labelled "Products" is named retailer-hub-c-products. Portals created before custom names got the _c ending have no c part, giving retailer-hub-products. If that name was already taken, -2 is added. Check by opening the page: a wrong name shows "Data view failed (404)".

Can two portals publish the same entity?

Yes. Each portal publishes its own data views, and several can use 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 it is withdrawn when the last one is deactivated or deleted.

Why does a public list look identical to a signed-in user?

That is by design. Public views always run as the shared anonymous identity, so a catalogue is the same for every visitor and signing in never changes it. Person-specific data belongs on an Authenticated view, which runs as the visitor.

Related topics

• Portals
• Build and publish a portal
• How portal security works
• Portal visitors and signup
• Troubleshooting portals
• The data model
• Security profiles