xMatix Portals

A portal is an external website built on your organization's data and published from Setup, such as a customer self-service portal, a product catalogue or 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 runs on its own hostname, separate from the application your teams sign in to. This page explains what a portal is made of, the publishing model that decides what visitors can see, and the administrator tasks around the portal register: create, configure, retract and delete. The step-by-step build is on Build and publish a portal.

Overview

A portal is listed on Setup → Feature Hub → Portals → Portals and is made of three kinds of configuration:

• The site sets the portal's identity and frame: a label, a slug (the hostname label the portal is served under), a description, theme tokens, header navigation, and switches for anonymous access, self-service signup and portal learning.
• Pages are addressed by path (/, /products, /support). There are four page types: Designed page, Entity list embed, Entity detail embed and App page embed. Each page has an audience: Public (anonymous + signed-in) or Authenticated users only.
• Data views are the only general way an authored portal page can read records. Each one publishes a single entity view (a column set plus a base filter) to the portal. An authored page cannot query an entity that has no published view. A portal linked to a commerce channel also uses the storefront's own catalogue, cart, checkout and account operations. Those are fixed workflows, not access to the general data interface. See Portal pages and data views and Portal storefronts.

One organization can run several portals side by side. Each has its own slug, address, pages, data views and theme. They share one organization-wide anonymous visitor identity and its Portal Anonymous security profile.

When to use it

Use a portal when people outside your organization need to read or act on a controlled slice of your data without an internal user account:

• a public product catalogue or price list;
• a customer area where signed-in customers see their own orders, invoices or cases;
• a partner or dealer site, including partner learning;
• a storefront that takes orders through a commerce channel (see Commerce).

Do not use a portal to give internal staff a lighter screen. Internal users belong in the main application, with security profiles and apps that match their job.

How xMatix handles it

Nothing on a portal becomes public by accident. A visitor's browser only gets content after three gates are opened, and each gate is an explicit action:

1. The site is published and active. A site that is unpublished or switched to inactive is not served at all, and visitors get "not found".
2. Each page is published. Page edits build up in a draft. Publish draft makes the current draft the served version. An unpublished page is invisible to the portal, and later edits change nothing until you publish again.
3. Each data view is active. Creating a data view with the Public audience gives the Portal Anonymous profile read access to that entity. The view's base filter and columns still limit what can be reached. Authenticated views do not use that grant. They run as the signed-in visitor, so that person's own record security decides which rows they see. The anonymous read grant on an entity is withdrawn automatically when the last active public view of that entity is deactivated or deleted, counting the views on every portal in your organization. The full model is in How portal security works.

Retracting reverses publishing at every level. Unpublish a page and it disappears from the portal. Unpublish the site and it stops being served to every visitor immediately. Retracting deletes nothing, so a portal can go offline and come back without rework.

Signed-in access is per portal. A signed-in external user counts as signed in only on the portals they are a member of. On any other portal they are treated as an anonymous visitor.

Prerequisites

• The Manage portals capability (setup.portals.manage) on your security profile. It is part of the metadata administration feature.
• The Portals product licensed and enabled for your organization. Without it, the Portals group does not appear under Feature Hub.
• The Enable Portals setting switched on (it is on by default). See Configuration.
• Before you create a portal, decide who owns it, who it is for, what hostname it will use and what data it is meant to expose. Treat every row in the register as security-relevant.

Procedure

Step 1 — Open the portal register

Open Setup → Feature Hub → Portals → Portals. The register lists every portal in your organization. Use the search box in the table header to find a portal by label, internal name or slug, and the column picker to show or hide columns.

Step 2 — Create a portal

Click New in the page header. In the New portal dialog, enter a Label. The Slug (portal hostname label) fills in from the label until you edit it yourself. Click Create. The new portal opens on its detail page with three tabs: General, Pages and Data Views. It starts unpublished (State: Draft), with Active switched on and Anonymous visitors switched off.

Step 3 — Configure the site

On the General tab, set the description and the switches described under Fields, then click Save. Site settings apply to the live portal as soon as you save. There is no draft for them.

Step 4 — Add pages and data views

Add pages on the Pages tab (Add Page), and publish the entity views your pages need on the Data Views tab (Publish Data View). Step-by-step instructions are in Build and publish a portal, and what each choice exposes is in Portal pages and data views.

Step 5 — Publish the portal

Click Publish in the page header and confirm. The portal can now be served. Visitors see only its published pages and active data views, and State changes to Published. The portal's address appears in the page header and in the register's Address column. Hostnames and custom domains are covered in Publishing, hostnames and custom domains.

Step 6 — Take the portal offline

Click Unpublish in the page header and confirm. The portal stops being served immediately, and State goes back to Draft. Pages, data views and settings are kept. To serve it again, click Publish. Switching Active off on the General tab also stops the portal being served, whatever its publish state.

Step 7 — Delete a portal

In the register, use Delete in the row's actions column and confirm. This removes the portal, all of its pages and its data views, and it cannot be undone. Your business records are not affected. When you only want the portal offline, unpublish it instead. Before deleting, deactivate or delete the portal's Public data views first, so the anonymous read grant on those entities is withdrawn (see Business rules).

Fields

The portal register

New portal dialog and General tab

The detail page header also shows State, Active, Anonymous, Pages, Data views and Version for the open portal.

Business rules

• Slugs are validated on the server. An invalid slug is refused with "Slug must be a valid DNS label (lowercase letters, digits, hyphens; max 63 chars).", a reserved one with "This slug is reserved." and a duplicate with "A portal with this slug already exists."
• New portals start closed. A new portal is active, unpublished and sign-in only. Nothing is served until you publish it.
• The module switch blocks new authoring. When Enable Portals is off, creating a portal, publishing a portal, adding a page and publishing a page are refused with "The Portals module is disabled for this organization.", and every portal answers visitors with "not found".
• Page paths are unique per portal. A second page with the same path is refused with "A page with this path already exists on the site."
• Public data views share one grant. The Portal Anonymous read grant on an entity stays while at least one active public data view of that entity exists on any of your portals. Deactivating or deleting a data view checks for this and withdraws the grant once none remain. Deleting a whole portal does not run that check. That is why Step 7 asks you to remove the public data views first.
• Data view page size is capped. The page size cap is between 1 and 250 rows per request, with 50 as the default.
• Changing a slug does not move a published portal. The address is registered when you publish. After you change the slug of a published portal, unpublish it and publish it again so the new address is registered.

Example

A distributor wants a public catalogue for retailers and a signed-in area where retailers see their own orders.

1. An administrator opens Setup → Feature Hub → Portals → Portals, clicks New, enters the label Retailer Hub, keeps the suggested slug retailer-hub and clicks Create.
2. On General, they add the description "Catalogue and order tracking for retail partners", switch Anonymous visitors on and leave Self-service signup off, because retailers are invited. They click Save.
3. On Data Views, they publish an item view with the Public audience, and an order view with the Authenticated audience.
4. On Pages, they add / (a designed home page), /catalogue (an entity list embed of the item view, Public) and /my-orders (an entity list embed of the order view, Authenticated users only). They publish each page with Publish draft.
5. They click Publish, open the address from the page header in a private browser window and check that the catalogue shows but My orders does not.
6. A month later the catalogue needs rework. They click Unpublish, make the changes, and click Publish again. Nothing was lost in between.

Training

Practice exercise

In a sandbox organization, create a portal called Training Portal. Switch Anonymous visitors on, add one designed page at /, publish the page and then the portal. Open the address in a private browser window. Then switch Active off, save, and reload the address.

Expected result: the register shows Training Portal as Published, Active and Allowed. The home page is served while the portal is active, and the address returns "not found" once Active is off, even though Published still reads Published.

Quick reference

• Register: Setup → Feature Hub → Portals → Portals; module switch: Setup → Feature Hub → Portals → Settings.
• Three gates: site published and active, page published, data view active.
• New portals start active, unpublished and sign-in only.
• Site settings apply on save; page content applies only on Publish draft.
• Public data views run as the shared anonymous visitor; Authenticated ones run as the signed-in visitor.
• Unpublish takes a portal offline without losing anything; Delete cannot be undone.
• Remove public data views before deleting a portal.
• After changing a published portal's slug, unpublish and publish again.

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 portal address says "not found"

Check, in order: Published reads Published, Status reads Active, Anonymous reads Allowed (or you are signed in as a member of this portal), and Enable Portals is on. If you changed the slug after publishing, unpublish and publish again. More checks are in Troubleshooting portals.

"The Portals module is disabled for this organization."

Enable Portals is off. Switch it on at Setup → Feature Hub → Portals → Settings, or ask an administrator who holds the Feature Hub settings capability.

"A portal with this slug already exists."

Another portal in your organization already uses the slug. Choose a different slug, or change the other portal's slug first.

The Address column is empty

This environment has no portal hostname configured, so no address can be built. Publishing still works. Contact xMatix support, or serve the portal on a custom domain.

I can't find Portals in Setup

Either your organization does not have the Portals product enabled, or your security profile lacks Manage portals. Check Licensing and your profile.

Common questions

Is a new portal visible to the public as soon as I create it?

No. A new portal is unpublished and sign-in only, and none of its pages or data views exist yet. Nothing is served until you publish the site, and visitors then see only pages you have published individually. Anonymous visitors see nothing until you also switch Anonymous visitors on. This lets you build the whole portal, test it, and decide exactly when it goes live.

What is the difference between Unpublish, switching Active off and Delete?

All three stop visitors reaching the portal, but they differ in what they keep. Unpublish takes the portal offline and keeps everything. Publish brings it straight back. Switching Active off on the General tab also stops serving while keeping everything, and leaves the publish state as it was. Delete removes the portal, its pages and its data views permanently. Your business records are never affected by any of the three, because a portal is a window onto your data, not a copy of it.

Can one organization run several portals?

Yes. Each portal has its own slug, address, pages, data views and theme, and you manage them separately in the register. They share one anonymous visitor identity and the Portal Anonymous profile, so the public data views on all your portals together decide what that profile can read. Review public exposure across all portals, not one at a time. Signed-in access is separate per portal: a member of one portal is an anonymous visitor on another.

Do site changes need publishing again?

No. The label, description, switches, theme and navigation apply to the live portal as soon as you click Save on the General tab. Page content works differently. A page keeps serving its last published snapshot until you use Publish draft. The one site change that needs a re-publish is the slug, because the portal's address is registered when you publish.

What's in this section

Related topics

• Portals on the xMatix site (the product overview)
• Portal storefronts
• Consumer accounts
• The xMatix security model
• Security profiles
• See a portal built in a demo