How portal security works

A portal is safe because xMatix lets it serve only published content, lets authored pages read records only through the data views you publish, and runs every read as a real identity that your organization's security model then checks. This page explains each of those rules, the anonymous identity and its Portal Anonymous profile, and how signed-in portal accounts are fenced off from the rest of the platform. It ends with a review procedure you can run before you publish a portal and again from time to time.

Overview

Every portal raises the same question: the site is on the public internet and shows business data, so what stops it from serving the wrong thing? xMatix answers it with a few rules that the platform enforces itself. They do not depend on how carefully someone designed a page. Once you understand them, "is our portal safe?" becomes a checklist you can work through, not a feeling.

The rules cover three kinds of caller:

• Anonymous visitors. Nobody is signed in. Their requests run as your organization's single anonymous identity.
• Signed-in portal users. These are external accounts created by signup or by an administrator's invite. They must be members of the portal they are visiting.
• Your own staff. Internal users count as signed in on every portal, so staff can preview what visitors see.

When to use it

Read this page before you:

• publish a portal or a Public data view;
• switch on Anonymous visitors or Self-service signup for a portal;
• grant anything by hand to the Portal Anonymous profile;
• answer an audit question such as "which of our records can someone without a login see?"

How xMatix handles it

Rule 1 — only published content is served

Visitors are never served page drafts, unpublished pages, the site's Settings document, or a site that is unpublished or inactive. A page reaches visitors only as the snapshot taken when you published it.

There is one exception to "published": data views. A data view has no separate draft. It is live from the moment you save it as Active on a published, active portal. Its audience, view and page size cap take effect on save too. See Portal pages and data views.

Rule 2 — authored pages read records only through data views

The pages you design on the Pages tab reach data through one narrow public surface. That surface can do five things:

• resolve the site;
• fetch a published page;
• query an active data view;
• accept a signup;
• answer whether the signed-in account may enter this portal.

It has no route to the platform's general data, metadata or administration interfaces.

Two kinds of portal also have their own purpose-built surfaces, each with its own checks:

• Commerce portals use the storefront for catalogue, cart, checkout, payment and customer-account workflows.
• Learning portals use the learner experience. It shows the catalogue offered to portal learners, and a signed-in learner sees only their own enrollments, progress, quizzes and awards.

Neither surface turns a page design into a general-purpose data client.

Rule 3 — every read runs as a real identity

• A Public data view always runs as your organization's anonymous identity, even when a signed-in user is looking at it. That way a public listing is identical for everyone.
• An Authenticated users only data view runs as the signed-in user, under that user's own security profiles, ownership and record-sharing rules. Someone who is not signed in gets "Sign in to view this data."

Either way, the standard security engine makes the decision: entity permissions, record-level security and field-level security. The portal adds no access rules of its own, so there is no second rulebook that can drift out of step with your security setup.

Every gate a record passes

A record reaches a visitor only if it passes every one of these layers, from the outside in:

The public surface is also rate limited. By default:

• a caller can run about 120 data-view queries a minute;
• signup allows five attempts per network address every ten minutes.

A caller who goes over the limit sees "Too many requests. Please wait a moment and try again." and can retry shortly.

The anonymous identity and the Portal Anonymous profile

Your organization has one anonymous identity, shared by all of its portals and by its storefronts. It is a synthetic external account. Its system name is System Anonymous, and it shows as Anonymous in Created By on rows that a visitor caused, such as a self-signup. The account can never sign in. Every portal record points to it, so you can always see which identity serves a portal.

The account holds exactly one security profile, Portal Anonymous. xMatix enforces that posture:

• Whenever a portal is created or its General tab is saved, xMatix re-applies it. The account is set back to active and external. The Portal Anonymous profile is restored if someone deactivated or deleted it. Any other profile someone assigned to the account is removed.
• If the identity is missing when a visitor arrives, xMatix provisions it on the spot.

Publishing a data view feeds the profile.

• Saving an active Public data view grants Read and View All on that view's entity to Portal Anonymous.
• Deleting or deactivating a Public view withdraws those two rights. This happens only when no other active Public view of the same entity remains on any of your portals.
• Authenticated users only views never need the grant, because they run as the signed-in user.

The automatic withdrawal removes Read and View All on that one entity, even if an administrator had also granted them by hand. Any other right on the entity (for example Create) stays, and so do grants on other entities.

What the profile holds out of the box. The seeded profile also carries Read (without View All) on four platform entities:

• Activity
• Approval Request
• Approval Action
• File Link

No authored page can query these entities unless you publish a data view on them.

One warning. The identity and the profile are shared across your whole organization. Anything you grant the profile by hand applies to every anonymous visitor on every portal and storefront. Grants on entities that have no data view, and rights other than Read and View All, are never withdrawn automatically. Treat widening this profile as publishing: do it only when you mean "public".

Signed-in portal accounts and their boundary

A signed-in portal user is an external account. Because external accounts and staff sign in through the same identity service, xMatix fences external accounts in at the API:

• Portal surfaces only. An external account can use only the portal, storefront and sign-in surfaces. Anything else is refused with "This account belongs to a partner portal and cannot use the tenant workspace APIs." This covers the record data interface, metadata and portal or commerce administration. So even if an external account reaches the staff app's sign-in, it cannot read your workspace data there.
• Membership is per portal. An external account counts as signed in only on portals where it is a member (the portal's Members tab). Signup and invites record membership of the portal they were made for. On any other portal of yours, the same account is treated as an anonymous visitor. A storefront bound to a portal refuses non-members with "This sign-in does not belong to this portal." See Portal visitors, signup and identity.
• Inactive accounts are refused. A deactivated account is refused with "Your user account is inactive in this workspace. Contact your administrator." wherever a signed-in session is required, including signing in.
• Staff count as signed in everywhere. Internal users pass the signed-in checks on every portal, so they can preview members-only pages. What they see in Authenticated users only views is decided by their own security profiles, which usually reach far more records than a customer's would.

Within those limits, external users' record access defaults to private. An authenticated view shows a person only the records they own or are linked to, unless your rules deliberately share more. See Record-level security and sharing.

What never leaves the platform

• Page drafts, because the portal serves only published snapshots.
• The site's Settings document. The renderer receives only two flags derived from it: whether signup is offered and whether signup creates a customer.
• Data from any entity that has no active data view on that portal.
• Records and fields that the identity running the read cannot see.
• A count of every matching row. The total that drives the pager is capped, so a visitor cannot trigger an unbounded count.

Published pages and data views are read-only. Signup deliberately creates identity records. A portal bound to a commerce channel can also create or update the narrowly scoped records that cart, checkout, payment and account workflows need. A learning portal can record a learner's own enrollment requests, progress and quiz answers. All of these writes go through purpose-built surfaces with their own checks. No general record-write endpoint is available to an authored page.

Procedure

Use this review before you publish a portal, after you change its data views, and as a periodic audit.

Step 1 — Check the portal's front door

Open Setup → Feature Hub → Portals → Portals and select the portal. On the General tab, confirm these switches match your intent:

• Active
• Anonymous visitors (new portals start with it off)
• Self-service signup
• Create customer on signup

The header summary shows State (Published or Draft), Active, Anonymous (Allowed or Sign-in only) and the number of pages and data views.

Step 2 — Review every data view

Open the Data Views tab. For each row, check four columns:

• Entity and View: is everything this view's base filter can match fine to treat as public?
• Audience: Public or Signed-in.
• Status: Active or Inactive.

For a Public view, open the entity view itself (Setup → Design Studio → Entities → the entity → Experience) and check its columns and base filter. Changes there take effect on the portal immediately.

Step 3 — Remove what should not be public

Select Activate / deactivate to stop serving a view, or Delete to remove it. The delete confirmation tells you that the portal stops serving the data immediately, and that the anonymous read grant is withdrawn if this was the last published view of the entity.

To change a Public view to Authenticated users only, do it in three steps: first deactivate the view, then edit its audience, then activate it again. If you change the audience in one edit, the anonymous grant stays in place.

Step 4 — Inspect the Portal Anonymous profile

Open Setup → Access Control → Profiles → Portal Anonymous → Entity Permissions. Every entity with Read and View All should match an active Public data view on one of your portals. Apart from the four seeded Read grants (Activity, Approval Request, Approval Action, File Link), any other right (create, update, delete) or entity was added by hand, and you should ask whether it is meant to be public. Remove anything that is not.

Step 5 — Review who can sign in

Open the portal's Members tab and confirm every member should have access. For each member's external account, confirm under Setup → Access Control → Users that the assigned profiles are external-scoped and grant only what that person needs.

Example

A distributor publishes a "Partner Hub" portal with two data views.

• Product range is a Public view over the item entity. Its entity view keeps only active, saleable items and shows only name, category and list price. Saving it grants Read and View All on items to Portal Anonymous. Every visitor, signed in or not, sees the same 50-row pages.
• My orders is an Authenticated users only view over orders. A retailer signed in to Partner Hub sees only the orders that their own record rules give them.

A month later, the same retailer opens the distributor's separate "Service Desk" portal. They are not a member of it, so Service Desk treats them as an anonymous visitor.

The team then retires Product range. Deleting it withdraws the item grant, because no other Public item view is active on any portal. A Read grant on supplier price lists that an administrator had once added to Portal Anonymous by hand stays, however, because no data view ever managed that entity. Step 4 of the review finds it, and the administrator removes it.

Training

Practice exercise

In a sandbox organization:

1. Create a portal and publish one Public data view on an entity.
2. Open Setup → Access Control → Profiles → Portal Anonymous → Entity Permissions.

Expected result: the entity now has Read and View All.

1. Deactivate the view with Activate / deactivate, then reload the profile.

Expected result: the entity's Read and View All are gone, as long as no other active Public view of that entity exists.

1. Finally, add Read on a second entity to the profile by hand, without publishing any view of it. Then publish and delete a view of the first entity again.

Expected result: the hand-added Read on the second entity is still there. The automatic withdrawal only ever touches the entity whose view you removed.

Quick reference

• Pages serve their published snapshot. Data views are live as soon as they are saved Active.
• Public views always run as the anonymous identity. Authenticated users only views run as the signed-in user.
• One anonymous identity and one Portal Anonymous profile serve every portal and storefront in your organization.
• Publishing a Public view adds Read and View All. Removing the last one withdraws only those rights.
• Hand-made grants on Portal Anonymous are public. Removing a view withdraws Read and View All on its entity, hand-made or not; nothing else is withdrawn automatically.
• An external account is signed in only on portals where it is a member.
• External accounts cannot reach your workspace APIs at all.
• New portals start with Anonymous visitors off.

Permissions

Configuration

Common problems

A public data view returns nothing, or "Portal is not ready to serve data"

Several things can cause this:

• The view is Inactive, or it belongs to a different portal.
• Your organization's anonymous identity could not be found or provisioned. In that case public data views are not served at all.
• Record or field rules exclude the rows from the anonymous identity.

Check the view's Status on Data Views. Then check that Portal Anonymous has Read and View All on the entity. If it does not, deactivate and reactivate the view to restore the grant.

A signed-in customer sees the public pages but is asked to sign in for member pages

Their account is not a member of this portal, so this portal treats them as an anonymous visitor. Add them on the portal's Members tab, or invite them for this portal.

"This account belongs to a partner portal and cannot use the tenant workspace APIs."

An external portal account tried to use the staff app. This is the boundary working as intended. Portal users should sign in through their portal's address.

"This sign-in does not belong to this portal."

An external account tried to use a storefront that belongs to a portal it is not a member of. Add the membership if the access is intended.

"Your user account is inactive in this workspace. Contact your administrator."

The account has been deactivated. Reactivate it under Setup → Access Control → Users if access should continue.

"Too many requests. Please wait a moment and try again."

The caller went over the public surface's rate limit, which is about 120 data-view queries a minute or five signups per ten minutes from one address. Wait and retry. Repeated hits from one source usually mean a script, not a person.

For more symptoms, see Troubleshooting portals.

Common questions

Is everything in a published data view public?

For a Public view, plan on yes. Its rows and columns are served to anyone, identically, by design. The security engine still applies: field-level rules can hide columns and record rules can exclude rows. Still, the sound practice is not to rely on those rules as the fence. Publishing a Public view grants View All on the entity to Portal Anonymous, so the view's base filter becomes the main boundary. Publish a public view only when everything its filter can match is fine to treat as public information.

Can portal visitors change data?

Not through a page layout or a data view. Both are read-only, and an Authenticated users only view changes who runs the read; it does not grant a write. Signup creates the visitor's identity. Commerce portals can write through their explicit cart, checkout, payment and account workflows, and learning portals can record a learner's own enrollments and progress. If a requirement needs general record editing, do not try to infer it from portal sign-in or a data view. That capability is not available to authored pages.

We deleted a data view. Is the entity still exposed?

Only if another active Public view of the same entity exists on any of your portals, or if someone granted the entity to Portal Anonymous by hand. The automatic read grant is withdrawn when the last public view goes. Deleting, deactivating or unpublishing a whole portal does not withdraw the grants of its public data views. Before you retire a portal, deactivate or delete its data views first.

Does the Portal Anonymous profile show up in our security administration?

Yes. It is a normal security profile, listed with your others under Setup → Access Control → Profiles. That is intentional: portal exposure is auditable in the same place you already audit access. Its publish-managed grants come and go with your data views, and the seeded profile also includes Read on four platform entities. Anything else on it was added by an administrator, and you should ask whether it is meant to be public.

Can a customer of one portal see another portal's member pages?

No. Signing in to your organization is not enough: an external account must be a member of the specific portal. On any other portal it is served as an anonymous visitor. That means it sees only public pages and Public data views, and none of them if that portal does not allow anonymous visitors.

Why can our staff see member-only pages on every portal?

Internal accounts pass the signed-in check on every portal, so staff can preview what members see. In Authenticated users only views, staff see whatever their own security profiles allow, which is usually much more than a customer would see. Use a test external account to check what customers actually receive.

Related topics

• Portal pages and data views
• Portal visitors, signup and identity
• Build and publish a portal
• Troubleshooting portals
• The xMatix security model
• Security profiles
• Record-level security and sharing
• Security and governance on the xMatix site