On this page
MSO Cloud is a multi-tenant SaaS platform. Every tenant is called an org. An org configures which parts of the platform it uses; the platform loads only the data, resolvers, and UI for the parts an org has turned on. No org sees every feature, and no org's data is visible to another.
Not a commerce data platform#
MSO Cloud carries the internal name Unified Commerce Intelligence Platform (UCIP). The name invites a misreading, so it is worth stating precisely what UCIP means: it is cross-system intelligence infrastructure, not a platform for unifying commerce data alone.
The reasoning: signals are not ground truth. A diagnosis built from signals is not ground truth. Historical memory is not ground truth. A marketing hypothesis, such as "this creator mix is building trust" or "this campaign is driving demand," has to be checked against something outside marketing's own reporting. Commerce keeps the name in UCIP because commerce outcomes, orders, conversion, revenue, are one of the platform's most reliable ground truths for that check. UCIP unifies several intelligence domains (social, creator, media, CRM, and commerce) into one context layer, and it uses commerce outcomes as a verification mechanism against that context, not as the sole subject of the platform.
How a tenant is composed#
An org is composed from pillars: named slices of the platform such as marketplace sales, marketing performance, CRM, social listening, market estimates, and audience research. See Data Foundation for what each pillar covers and how reliable its data is.
A pillar becomes active for an org in one of two ways. Five of the six pillars are gated by a plugin: the org must have that plugin enabled before the pillar's data, resolvers, and translated UI strings load at all. The sixth, marketplace sales, has no owning plugin; it is the platform's default and turns on the moment an org has a live marketplace connector or any order history, including imported or historical orders from a marketplace that has since been disconnected.
flowchart LR PLUG["Plugins enabled for the org"] --> RES["Pillar resolution"] CONN["Live marketplace connector, or order history"] --> RES RES --> SET["The org's active pillar set"] SET --> NAV["Navigation and pages shown"] SET --> DATA["Data, resolvers, and translations loaded"]
Two consequences follow directly from this. First, adding a new client is a configuration and data task, not a code change: the pillar, plugin gate, and connector families are built once, and a new org arrives with a template plus vocabulary, not a new code path. Second, an org built around a single pillar can look very different from another: an org that only does audience research has no commerce figures to show, so its landing surface is a set of delivered decks rather than a sales dashboard.
Below the pillar layer, an org is partitioned into brands. Tenancy is enforced inside the database, not only in application code: every org-scoped table carries a row-level security policy keyed to the org (and, where relevant, the brand) of the current request, and that enforcement holds even for code with a bug in it. Each org can also be reached through its own subdomain or a white-label domain, which the platform pins to the org before any request touches its data.