Portals serve people who are not members of your organization, and the identity model takes all of them seriously — including the ones who never sign in. Three kinds of visitor exist: anonymous visitors, people in the middle of signing up, and signed-in portal users. This page explains what each one is in your organization's terms, because that is what decides what they can see. Sign-in on the portal surface itself is the newest layer of the portal stack and is still rolling out; the identity model below is what it builds on.
Anonymous visitors are a real identity
An anonymous request is not a security exception. The organization has one tenant-wide synthetic visitor principal shared by all of its portals, carrying the least-privilege Portal Anonymous security profile. Anonymous reads execute as that identity, so the same security engine that protects the application decides what the portal serves; there is no separate rulebook for public traffic. The account itself can never be signed in to — it exists only as the identity anonymous reads run under.
The site's Anonymous visitors switch controls whether anonymous viewing is allowed at all: switched off, the portal serves signed-in external users only, and anonymous visitors get nothing — not even the page list.
Self-service signup
Demo2 currently has no portal row, so the two signup switches cannot be shown without creating production configuration. An empty registry would not evidence their state, and this page deliberately avoids reusing it. On a configured portal, Self-service signup admits signup requests. Create customer on signup controls whether a successful signup also provisions the fresh consumer Account and Contact that commerce views need; it defaults on unless an administrator explicitly switches it off.
With Self-service signup enabled on the site, visitors can create their own account by submitting an email address, optionally with a name and phone number. What happens next:
- When Create customer on signup is on, xMatix first creates a new consumer Account and Contact from the submitted identity details. It never searches by email and adopts an established customer record, because an anonymous caller must not be able to claim one.
- An external account is created and linked to that newly created Contact. The same save also records membership of the portal the visitor used; the account is not automatically admitted to the organization's other portals.
- The person receives an email inviting them to set a password, which activates sign-in.
- The response is deliberately uninformative: whether the email was new or already registered, the visitor receives the same accepted acknowledgement, so signup cannot be used to probe which addresses hold accounts.
If Create customer on signup is explicitly off, signup creates an unlinked external login instead. Commerce reads have no customer account to resolve until an administrator links that login through the invite/linking flow. In both modes, signup never attaches the visitor to an existing Account or Contact by email; adopting an established customer remains an administrator action.
What a signed-in portal user is
A signed-in portal user is an external account: a real account in your organization with an external audience, created by signup or by an administrator's invite. External accounts are not internal seats — they do not appear among your workforce, and they hold only the access their external-scoped security profiles and record-security rules give them. The account must also have membership of the portal it is entering. In the authored portal layer, being signed in unlocks two things:
- Authenticated pages — pages whose audience is signed-in users only.
- Authenticated data views — "my records" surfaces that execute as the signed-in person, so ownership and sharing rules scope the rows to theirs. A customer whose account is linked to their customer record sees their own orders; nobody else's.
Public pages and public data views, by contrast, never change with sign-in: they always serve the anonymous identity's view of the data, identical for everyone.
If the site is also bound to a commerce channel, the signed-in external account can use the storefront's separately governed account and transaction flows as configured. That commerce surface does not make an Authenticated data view writable and does not bypass the portal-membership check.
Common questions
Do portal accounts consume internal user seats?
No — external accounts are a separate population from your internal named users, and a visitor creating one does not occupy an internal seat. Portal signups are recorded as usage events so the organization's portal activity is meterable; for how licensing is structured, see Licensing.
Why does signup always report success?
Because a different answer for already-registered emails would tell strangers which addresses have accounts. New addresses get an account and a set-password email; existing addresses get nothing new — and both see the same acknowledgement. A visitor who already has an account should sign in instead.
Can someone sign up and still see nothing new?
It depends on the site's Create customer on signup setting. With the default on, a new signup is linked to the fresh consumer Account and Contact created for it, so commerce surfaces can resolve that new account immediately; it still cannot inherit an established customer's records by matching email. With the switch off, the login is intentionally unlinked and personal commerce surfaces remain empty until an administrator links it. In either case, entity permissions, record rules, data-view audience and portal membership still have to admit the read.