On this page
A tenant in MSO Cloud is not one fixed product. It is composed from plugins, and each plugin resolves to one of six data pillars: ecom, marketing, social, crm, market, audience. An org's plugin set decides which pillars are active, which pillars decide which dashboards, morning-brief rules, and decision-engine surfaces the org actually sees. Two orgs with different plugin sets run different products on the same platform, and their data never blends across planes.
Beside the pillar-bearing shapes sits a second family: a workspace that runs on datasets the org declares itself, with a domain layer — human resources, finance or warehouse — stacked on top. Those layers carry no pillar; see "Dataset workspace org" and "Composed shapes" below.
flowchart LR
subgraph Plugins
P1["marketplace connectors"]
P2["marketing connectors"]
P3["social-intelligence"]
P4["market-intelligence"]
P5["content-intelligence"]
P6["mso-offtake"]
end
subgraph Pillars
E["ecom"]
M["marketing / crm"]
S["social"]
K["market"]
A["audience"]
end
subgraph Surfaces
D1["Orders, Inventory,\nCreators, Reports"]
D2["Marketing\nPerformance"]
D3["Social\nIntelligence"]
D4["Market\nIntelligence"]
D5["Content Intelligence\ndecks"]
D6["Briefing, Decisions,\nPlaybooks"]
end
P1 --> E --> D1
P2 --> M --> D2
P3 --> S --> D3
P4 --> K --> D4
P5 --> A --> D5
P6 --> D6
E --> D6
M --> D6Marketplace / eCom org#
Plugins: the marketplace connector family (TikTok Shop, Shopee, Lazada, CSV import for Shopee/Lazada, Warehouse), plus optional standard dashboards, live-commerce reporting, service-recovery case handling and outbound activation.
Pillar: ecom, the platform default. It has no owning plugin and turns on as soon as the org has a live marketplace connector or any order history.
Surfaces: Orders, Products, Inventory, Creator directory, the commerce performance report, settlement report, live commerce report, cohort/RFM/KOL report, and data validation. This is the platform's money plane, checked by an automated reconciliation gate against a ground truth kept outside the codebase.
Morning brief and alert rules: the eCom collector is the one fully generalized today, covering GMV, margin, inventory, creator performance and returns on a daily cadence. Org admins mute, snooze and route this pack under Settings; see Morning Brief.
Decision engine: this is where the off-take loop is shipped end to end, correlation and forecast statistics against the org's own weekly GMV history, a policy learner, guardrails, a human approval gate, and measurement against first-party orders after activation.
Marketing org#
Plugins: the marketing connector family (Google Ads, Meta Ads, TikTok Ads, Shopee Ads, GA4, Google Search Console, Google Sheets, LinkedIn Page, Brevo) plus Marketing Performance.
Pillars: marketing (ad spend, web analytics, search behavior, first-party against the org's own accounts) and crm (lead and deal tables). The CRM pillar is partial: feeds are commonly thin, and a metric abstains rather than guessing when a lead or deal feed is not connected.
Surfaces: Marketing Performance, covering KPI pacing, ad spend, web and search behavior, leads, campaigns, email and social channel figures.
Morning brief and alert rules: the marketing collector wires the org's existing per-campaign audit signals into the shared signal store, covering spend, cost per lead, delivery cost, click-through, landing-page drop-off, frequency and pacing. The default pack has eleven rules, and a catalogue of sixteen playbooks runs the weekly judgement over the same signals. See Morning Brief and Marketing Playbooks.
Decision engine: a marketing org points the definable-conversion registry at leads, deals or deal value instead of orders or GMV. The same decision loop and Measure Spine reconciliation run against that chosen conversion, resolved through the CRM's marketing-qualified-lead and won-deal definitions; when the feed is thin the resolver returns null rather than a number it cannot support.
Social / content-intelligence org#
Plugins: social-intelligence (third-party social listening: buzz and sentiment) and content-intelligence (the org's own client-approved audience corpus and decks).
Pillars: social is a third-party signal, used to form a hypothesis and never to score a KPI. audience is treated as first-party even though the underlying feed is a third-party crawl, because it is a client-approved deliverable; it sits inside the same reconciliation gate as orders and ad spend.
Surfaces: the Social Intelligence hub (listening, trends), and for content-intelligence orgs the Taxonomy Studio (per-client vocabulary) and Layout Studio (deck authoring); delivery decks themselves are saved dashboards rather than a separate nav item.
Morning brief and alert rules: a social-pillar brief is planned but not yet in the default rule packs. A content-intelligence corpus deck is explicitly excluded from the morning brief; it is a delivered document, not an operational surface.
Decision engine: social signals can feed a playbook's diagnostic step as supporting evidence, but never as the measured outcome. Content-intelligence decks sit outside the decision loop entirely.
Market-intelligence org#
Plugin: market-intelligence, fed by third-party market-estimate connectors plus the shared social-listening connectors (SocialHeat, SocialTrend) and YouNet ECI.
Pillar: market, third-party category, competitor and combo estimates. Every number here carries an estimate label and is excluded from the first-party reconciliation gate, because a market estimate has no external ground truth to reconcile against.
Surfaces: the Market Intelligence hub, market trends, competitors, market creators (with a human review queue for the creator-vs-brand-account classifier), products and opportunities, livestream, and the raw market intel data view. Every page badges its numbers as estimates.
Morning brief and alert rules: a market-plane brief needs a sanctioned market-plane reader that has not shipped yet; this is the least mature part of the brief system today.
Decision engine: market estimates never become a first-party KPI or a measured decision outcome. They can inform a recommendation's reasoning, never validate it; validation still runs against the org's own first-party data or its chosen conversion.
Dataset workspace org: HR, finance, warehouse#
Plugins: the Google Sheets connector plus the assistant; every marketplace connector is turned off.
Pillars: none of the six above. A dataset workspace runs on datasets the org declares itself, and its domain layer — hr, finance or warehouse — carries the standard for that domain as versioned data: the field set, the derived measures, the dashboard pages and the morning-brief legs. Activating the layer installs that standard; nothing is written per customer.
Surfaces: the pack's pages as saved dashboards, plus data uploads, mapping templates and connectors. An HR workspace opens eight pages, a finance workspace four, a warehouse workspace four.
Morning brief and alert rules: hr and warehouse each declare a reader and grant the Briefing surface — a people reader and an operations reader. finance declares neither yet, so a finance-only workspace paints no Briefing entry at all rather than an empty page.
Decision engine: no lever. The platform sends no command into an HRM or an ERP and has no measured response variable comparable to off-take, so the decision engine abstains on these workspaces instead of falling back to commerce levers.
See Loại tổ chức: Nhân sự, Loại tổ chức: Tài chính and Loại tổ chức: Kho vận, and Bộ dữ liệu và chỉ số for how a dataset becomes a measure.
Composed shapes#
An org's shape is a stack, not a single choice: one base workspace plus zero or more domain layers. Two things follow from that.
A domain layer composes onto any base. warehouse is the clearest case — a commerce org that also runs a warehouse activates the warehouse layer on top of its commerce base and reads both, rather than moving to a different workspace type. The layer brings its own pack, its own brief legs and its own nav grant; the base keeps everything it had.
A layer may lower the stack's answer, never raise it. Signals and the morning brief fold across the stack: the base decides first, and any layer that says "no brief here" wins. That is why "briefing on by default, except the content-intelligence workspace" is one row of data rather than a list of org ids somebody maintains.
Three stacks ship as ready-made shapes in the provisioning picker — hr-workspace, finance-workspace and warehouse-workspace, each the dataset workspace plus one layer. A stack the picker does not offer is a missing declaration, not a missing feature: see Tạo tổ chức mới cho một khách hàng.
Mixed org#
Most production tenants run several pillars at once, for example marketplace orders plus marketing spend plus market estimates. Each plugin still resolves independently to its own pillar, surfaces, brief pack and decision measurement; the three data planes (first-party marketplace, first-party marketing, third-party market intel) never mix regardless of how many are turned on for one org. A super admin seeds the initial plugin set for a new org from a blueprint, and can enable additional plugins per org afterward.