When the commerce experience must reach people outside your organization — dealers browsing your range, customers checking their orders, consumers buying — it is delivered with xMatix Portals: external-facing sites you author in your tenant and publish on their own hostname. Portals are an early-availability capability; this page describes what a portal storefront does today, which surfaces can transact, and how multiple portals stay separate. There is no screenshot because the surfaces described here are portal-side pages, which exist only on a published portal in your own tenant; the administrator screens are covered in the Portals section.
What a portal storefront is
A portal is a site of pages served to external visitors — never through the internal app shell. Administrators create and manage sites under Setup → Feature Hub → Portals, where the registry lists each portal's name, slug, address, published state, status, anonymous access, page count and version. A site's record has three tabs — General, Pages and Data Views — and a header showing its address (a Draft tag until published) with a Publish / Unpublish action.
On General: the label, description and slug (the hostname label — lowercase letters, digits and hyphens), Active, Anonymous visitors (off means only signed-in external users can view the portal), Self-service signup, Create customer on signup, and an Advanced section holding the theme, navigation and settings documents as JSON. Pages are designed free-form or embed a platform surface — an entity list, an entity detail, or an app page — each with a Public or Authenticated audience. Authoring is draft-first: visitors only ever see the published snapshot of a page, an unpublished page is invisible, and an inactive or unpublished site is not served at all. Custom hostnames are attached under Domains (publishing and domains).
Catalogue surfaces: published data views
A portal reads tenant data only through published data views — entity views a tenant has explicitly published to that site on its Data Views tab. Each names the entity (fixed once published), the view whose columns and base filter bound what is reachable, an audience, and a page size cap (up to 250 rows). There is no general data access from a portal.
Who a view serves decides whose identity runs the query:
- Public views execute as the portal's own anonymous service identity — so every visitor, signed in or not, sees the identical catalogue, and record and field security are enforced through the standard engine rather than a parallel path.
- Authenticated views require a signed-in external user and execute as that caller, so ownership and contact-link security scope the rows — the mechanism behind "my orders" style surfaces.
A visitor's request can only narrow a view's filter, never widen it. Publishing a view grants the portal's anonymous identity read access to that entity; deactivating or removing the last published view of the entity revokes it. Exposure is therefore an explicit, reviewable list per site — see pages and data views.
Signing up and signing in
With Self-service signup on, a visitor leaves an email, name and phone and receives a set-password invitation, creating an external user account that is a member of that portal. With Create customer on signup (on by default) the signup also provisions a consumer Account and a linked Contact named for the person, so commerce screens resolve their account immediately — without it the new login is a dead end that cannot see an account. The response is identical whether or not the email already had an account, so signup cannot be used to probe who your customers are; and a signup never adopts an existing customer's records — connecting a known customer to a login is done by invitation from inside the platform. Signup is rate-limited per caller. Details are in consumer self-signup and accounts and visitors and signup.
Each portal is its own boundary
A tenant can run several portals — a dealer portal, a consumer storefront, a service-partner site — and they are separated by more than navigation:
- Membership. Inviting a user to a portal, or their self-signup on one, records them as a member of that portal, and sign-in pins the session to it. To a portal they do not belong to, an external user is simply an anonymous visitor.
- Audience. External logins reach only the portal and storefront surfaces; the internal data, metadata and admin APIs refuse them outright, regardless of what security profiles the account carries.
- Order books. Each order is stamped with the channel it was placed on, and a portal's order history shows only its own channel's orders.
- Money stays whole. Invoices, ledger and credit exposure are account-level on purpose: what a customer owes is one number however many portals they shop through, so a credit limit cannot be evaded by switching storefronts.
Two kinds of surface on one portal
A portal serves two different kinds of surface, and the distinction decides what a visitor can do:
- Portal pages and published views are the read layer: merchandised browsing, record lists, "my orders" style surfaces. They are read-only for external audiences — a page-embedded entity surface never writes.
- The commerce storefront is the transacting layer. A commerce channel of type portal linked to the site gives visitors the published catalogue with a real cart, checkout and payments; each order lands in the same pipeline as every other order. The link between a site and its channel is made on the channel record, and the store's record lists the channels selling from it.
Dealers who order through back-office channels — the Product Catalogue cart inside the apps, the purchase-order handoff, field-sales capture — keep doing so; those channels are described in Dealer ordering. The storefront adds a self-service lane beside them; it does not replace them.
Common questions
Can the portal show each dealer their own prices?
Public catalogue views cannot — by design they run as the shared anonymous identity, so every visitor sees the same rows and columns, and the published catalogue shows one displayed price per listing. Account-specific commercial terms resolve at checkout: the cart pricer prefers a price list named for the signed-in customer, then one for their customer account group, then a general list, and never prices from a list the shopper is not entitled to. An authenticated view can scope records to the signed-in user, which is how account-specific surfaces are built.
Can a dealer place an order from the storefront?
Yes, where the site carries a storefront channel: the cart and checkout are real, and a placed order joins the same order book as every other channel — including pay on account for customers within their credit terms. Portal pages and published views remain read-only; it is the storefront surface that transacts.
Is portal data a copy that can go stale?
Published data views read live platform data at request time through the same security engine as internal users — there is no export or sync step; only the view's filter and columns limit what is exposed. The storefront catalogue is different: it is a published projection whose displayed prices and stock refresh only when the store is republished, while checkout always reprices against current rules.