MSO Cloud · Documentation

User Guide

Source: docs/guides/user-guide.md Updated 2026-09-21
On this page

MSO Cloud assigns each member of an org one role: owner, admin, editor, or viewer. A role decides which menu items are visible by default and which actions the backend accepts; a hidden menu item is not a security boundary by itself, the underlying capability check is. See the full role and operation reference for the generated, per-role menu list.

flowchart LR
  subgraph ROLES["Roles"]
    direction TB
    OW["Owner"]
    AD["Admin"]
    ED["Editor"]
    VW["Viewer"]
  end
  subgraph AREAS["What they reach"]
    direction TB
    DASH["Dashboards + reports"]
    OPS["Inventory, pipeline, connectors"]
    FIN["Payouts + reconciliation"]
    CFG["Tenant configuration"]
  end
  OW --> DASH
  OW --> OPS
  OW --> FIN
  OW --> CFG
  AD --> DASH
  AD --> OPS
  AD --> FIN
  AD --> CFG
  ED --> DASH
  ED --> OPS
  ED --> FIN
  VW --> DASH

Owner#

Owner and admin hold the same full capability set — every operational and configuration surface. The one thing only an owner can do: create or remove another owner.

Full role reference: Owner

Admin#

Identical capability set to owner — every operational and configuration surface the org has enabled. An admin cannot create, remove, or otherwise touch an owner.

Full role reference: Admin, plus the Administration Guide.

Editor#

Day-to-day work on the org's data: uploads, dashboards, reports, finance, inventory, creators, audiences, service cases. Not tenant configuration — members, connectors, AI, actions, playbooks and outbound activation stay owner/admin-tier.

Full role reference: Editor

Viewer#

Read-only access to the org's published reports and self-serve exploration; changes nothing.

  • Read commerce, settlement, live and cohort reports: Access reports
  • Query self-serve analytics through the semantic layer: Explore data

Full role reference: Viewer

Cross-role basics#

  • Dashboards. Every dashboard supports a date range and a comparison period (previous period or previous year); charts and KPI cards recompute against both. See Customizable Dashboards for how a dashboard is built and saved.
  • Trang, Bảng, Thẻ. A report is three levels deep and no deeper: a Trang (Page) is what a menu item opens, a Bảng (Dashboard) is a tab inside it, and a Thẻ (Card) is one chart, KPI, table or AI block on a flat 12-column grid. A filter is declared at one level and reaches only what sits under it: an org-wide filter, then the Trang, then the Bảng, then a cross-filter from clicking a card, with the nearest declaration winning. A sibling Bảng is never touched by another Bảng's filter, and a card that cannot express a filter says so on its face instead of quietly drawing everything. The full rules, with a worked example, are in Cấu trúc phân cấp bố cục.
  • Filters. Platform, brand and category filters on a report scope its data to what that filter combination actually covers; a filter with no matching data reads as empty, not zero.
  • Exports. Reports and dashboards support exporting the current view; see Exports for the supported formats and what carries over.
  • Data assistant. The in-app chat assistant answers questions over the org's own semantic layer when the org has enabled it; it never crosses into another org's data or into a data plane the org has not turned on.
  • Data validation. When a number looks wrong, Data Validation compares an uploaded export against what the connectors actually ingested, which is the first place to check before assuming a dashboard bug.
  • The daily brief. Organizations running a commerce, marketing, market or social plane get a Morning Brief at 07:00 Vietnam time. It is written for a role - an owner, an editor or a marketing voice, chosen by the data planes the org runs - and it is reachable by a member holding the AI-management capability, owner or admin by default. It stays quiet on a quiet day rather than padding itself.
  • Notifications. A bell in the dashboard header holds every notification addressed to you; while anything is unread, the browser tab carries a (n) count and the favicon a small dot, both cleared the moment the count reaches zero. Opening the bell, or the full inbox at Cài đặt > Thông báo (/settings/notifications), marks a row read; a "đánh dấu đã đọc" action clears one row or every row at once. That page is also where you choose what reaches you, in two steps. First the channel card at the top: turn browser notifications on for the device you are reading on, link your Telegram account, link your Zalo account — each with a one-time code you send to the bot or the official account — and unlink any of them again at any time. Email needs no linking; it goes to the address you sign in with. Then the matrix below: one row per notification type, one column per channel the platform offers (in app, browser, email, Telegram, Zalo today), for the whole org or for one brand at a time. In-app is the only place anything appears until you tick a cell yourself, for every type, including one a pack just installed for the org. The ROWS are what your org can actually be told about: a type only appears where the org runs that part of the product and holds the data behind it, so a workspace with no sales data is not offered a revenue alert it could never receive. A column you have not linked, or that a super admin has not configured or has not turned on for your org, is disabled with the reason printed on the cell rather than left to fail silently.
  • Muting one alert rule. For the alert types the platform ships (thiếu hàng sắp xảy ra, GMV bất thường, tỷ lệ hoàn cao, và tương tự, including a tenant's own dataset rules), Cài đặt > Cảnh báo (/settings/alerts) answers one question per rule: whether it reaches you at all. Turn a rule off there, or snooze it for 24 hours or 7 days, and nothing from it arrives — not in the bell, not on any channel. WHERE a notification arrives is chosen once, per notification type, on the notification settings page above; this page no longer asks it a second time. Platform infrastructure notices (a failed sync, a vendor outage) never reach an org member; they go to super admins only.
  • Playbooks and decisions. A playbook is a numeric rule that fires on its own and proposes a draft; a person approves, acts, and afterwards confirms what happened. That confirmation is the only thing the platform learns from - a machine verdict never feeds back. What a confirmed track record is then allowed to change, and at what sample size, is set out in Governance and Honest Numbers.
  • What opens after you sign in. A super admin always lands on the platform console; everyone else lands on the first surface their workspace actually paints, in a fixed order: the retail report pack's Overview, then Marketing Performance, then Market Intelligence, then the generic editable dashboard canvas (Trang chủ, /dashboard), then the saved-dashboard list — each one skipped when the org has not enabled it or has hidden it from the menu. Two exceptions inside that order: a viewer role skips the editable canvas and opens the data-explorer instead, since a viewer cannot edit a canvas; and the saved-dashboard list, when the org has not saved one yet, opens Connectors or Data Uploads instead of an empty list - wherever the org's data actually arrives. A workspace with none of these candidates falls back to the saved-dashboard list.