Every platform demo shows you one portal. The procurement question is what happens with three: a dealer ordering portal, a consumer storefront, a service-partner portal — same tenant, same customer master, same order pipeline. The failure modes are predictable and mostly invisible in a demo: a login created for one portal quietly working on another; a "members-only" page readable by anyone with any account; a partner's order list leaking another channel's orders; and — the expensive one — an external login that can reach the internal data API, where record-level grants designed for staff read far too generously. If you are evaluating any multi-portal platform, xMatix included, these are the questions to ask. Here is how xMatix answers them.
Externals live behind a different door
The first boundary is not between portals but between audiences. Every login is marked internal (staff) or external (portal users), and the API enforces the split in middleware, before any endpoint logic runs: an external token can reach the portal surface — public portal reads, the storefront API, the identity endpoints — and nothing else. The internal data and metadata APIs, the admin surfaces, the configuration endpoints all answer an external caller with a flat refusal, regardless of what roles or grants the account carries. The reasoning matters: portal users do hold security profiles, because the portal's own server needs them to read data on the user's behalf. Relying on those grants alone would mean one over-generous profile away from an external user browsing the raw data API. An audience gate is not subtle, which is the point — it fails closed even when configuration is wrong.
A login belongs to a portal
Within the external audience, membership is explicit: 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. Present that session on a different portal's address and it is refused outright, forcing a fresh sign-in rather than a quiet cross-walk. Authentication itself is portal-scoped: to a portal you do not belong to, you are simply an anonymous visitor, which also means "any authenticated user" never satisfies another portal's members-only pages. The practical consequence for an administrator is pleasantly boring — there is no cross-portal access matrix to audit, because the default is none.
The storefront checks the door too
Boundaries that live only in the web tier rot, because new endpoints forget them. So the same site scoping is enforced server-side across the whole storefront surface: a storefront channel bound to portal A refuses to answer on portal B — indistinguishably from a channel that does not exist — and every account, cart and checkout endpoint demands portal membership from external callers at one chokepoint, rather than trusting each endpoint to remember. Meanwhile each order is stamped with the channel it was placed on, and a portal's order history shows only its own channel's orders. One deliberate exception is worth understanding rather than discovering: money is account-level, not portal-level. What a customer owes is one number however many portals they shop through — invoices, ledger and credit exposure do not fragment per portal, because a credit limit that could be evaded by switching storefronts would not be a limit.
Wrong door, plain answer
The everyday case is less dramatic than an attack: a customer bookmarks the staff workspace, or a staff member signs into the portal app. Ambiguous half-broken screens are how support tickets are born, so a portal login reaching the staff workspace gets a plain, full-page explanation and a pointer to their portal — while the API behind it was never going to answer anyway. The user experience is a courtesy; the middleware is the boundary. When you evaluate this, test the impolite paths: paste portal-A cookies onto portal B, call the data API with an external token, request another channel's orders by id. The marketing pages will not tell you what happens; the error responses will.
Why one tenant at all?
Given all this machinery, why not simply run three tenants? Because the point of a portal is the shared substance behind it: one customer master, one item master, one order pipeline, one ledger. A dealer's portal order and the order a rep keyed for them must land in the same book; the consumer storefront must sell from the same published catalogue the commerce engine prices everywhere else; the service partner's claims must settle into the same accounts finance reconciles. Separate tenants give you isolation by amputation. The multi-portal architecture gives you isolation by boundary — shared where the business is shared, separated where the audience is — which is what portals are for. The same principle, applied to the storefronts themselves, is described in A storefront for every distributor.
The evaluator's checklist
Distilled, the questions to put to any multi-portal claim — ours included, in a proof of concept rather than a slide review: Is there an audience boundary below the application layer, and does it fail closed? Is portal membership explicit, and is a session pinned to the portal it signed into? Are members-only reads scoped to the portal, or merely to "authenticated"? Are order books separated by sales channel while money stays whole at the account? And when the wrong login lands in the wrong place, does the system explain itself — or produce a screen of elegant, silent failures? Platforms that answer those five cleanly were designed for many portals; platforms that answer with roles and custom development were designed for one, and are selling you the plural.