SG-Dashboard

The account-level cockpit — one per customer organization, every site under it.

SG-Dashboard lives at dashboard.sgen.com. It is the multi-site operations and portfolio visibility layer in SGEN — the surface where account owners and operators manage site readiness from above the site itself, and the routing layer into the per-site administration that lives further down in the admin.

This page is the Reference definition of the surface. It explains what SG-Dashboard owns, what it routes into, and how it should be understood inside the wider SGEN operating model. It is not a task guide and not a feature tutorial — those live in Guides.

What is this for?

Read this page when you want the structural definition of SG-Dashboard — what surface it is, where it sits in the platform model, what kinds of operations belong here versus deeper in the admin, and how the navigation model is shaped. It is the entry-point Reference for everything else inside the SG-Dashboard section.

The page is a Reference definition. It does not walk you through a procedure. Step-by-step procedures live in Guides. Per-release behavior change lives in What's New and Changelog. Per-area capability detail lives in the SG-Dashboard sub-pages (Site Manager, Billing, Integrations, Analytics, Reports, Client Manager).

Good use cases

• You are new to SGEN and want to understand what dashboard.sgen.com is for before opening any individual panel.
• You are scoping a multi-site rollout and need to know what lives at the account tier vs the site tier.
• You are explaining the platform shape to a stakeholder, an in-house operator, or an agency client and need a clear definition of the cockpit surface.
• You hit an action somewhere in the platform and want to confirm whether it belongs in Dashboard, in the admin, or in SG-Builder.
• You are designing a multi-team operations workflow and need the boundary between account-level and site-level responsibilities laid out.

What NOT to use this for

• Step-by-step procedures — open the relevant Guide.
• Per-area deep detail — open the corresponding SG-Dashboard sub-page (Site Manager, Billing, Analytics, Client Manager, Integrations).
• Site content, modules, or store administration — that lives in the admin, not in SG-Dashboard.
• Visual page composition — that lives in SG-Builder, opened from inside the admin.
• Marketing claims about SGEN's positioning — sgen.com is the marketing surface; this page is the docs surface.

How this connects to other features

• Platform Overview — the system map that places SG-Dashboard inside the three-surface model (Dashboard / Admin / Builder).
• Site Manager — the site-card cockpit inside SG-Dashboard for per-site routing, settings entry, and operational actions.
• Billing Overview — the account-level subscription, capacity, and payment surface.
• Analytics — multi-site reporting and analytics rollups at the account tier.
• Client Manager — for agencies and operators managing multiple client accounts.
• SG-Admin Overview — the site administration layer that SG-Dashboard routes into.

Definition

SG-Dashboard is the multi-site operations layer in SGEN. One Dashboard per customer organization. It serves as the account-level command surface for provisioning, portfolio visibility, billing access, site settings entry, integrations routing, and reporting actions across every site the account owns.

Operators who manage one site land at SG-Dashboard, see that one site's card, and click into its SG-Admin. Operators who manage many sites land at SG-Dashboard, see every site's card, and route into whichever site's SG-Admin is needed for the work in front of them.

The defining property is shape, not size. SG-Dashboard is account-tier; SG-Admin is site-tier; SG-Builder is page-tier inside that site. The address bar tells you which tier you are operating in at any moment — dashboard.sgen.com/... for SG-Dashboard, {site-domain}.com/sg-admin/... for SG-Admin, the visual editor surface inside the admin for SG-Builder.

Purpose

The purpose of this page is to define SG-Dashboard's role within the platform and distinguish it from site-specific administration and visual editing surfaces. It establishes what SG-Dashboard owns, what it routes into, and how it should be understood in the wider SGEN operating model.

The cockpit framing is intentional. SG-Dashboard is not a single-purpose screen — it is the navigation and control surface from which account-level operations either complete in place (billing, invitations, support tickets) or route into site-tier work (open this site's SG-Admin, edit a setting, run a report).

Scope

This page covers SG-Dashboard at the Reference level — the surface as a platform control layer rather than as a step-by-step workflow or feature tutorial.

The page covers:

• The account-level and multi-site operational role.
• The portfolio visibility and setup-entry responsibilities.
• The billing and capacity access surface.
• The operational routing into site-specific work.
• The dependencies and related surfaces SG-Dashboard touches (SG-Admin, SG-Builder, Workflows, Integrations).
• The constraints that keep account-tier work and site-tier work cleanly separated.

The page does not cover:

• Per-area procedures — those live in Guides.
• Per-area capability detail — those live in the SG-Dashboard sub-pages.
• Site administration — that lives in the admin.
• Layout composition — that lives in SG-Builder.
• Per-customer infrastructure detail — escalate to support for that.

Responsibilities

SG-Dashboard is responsible for the operating layer above individual site administration. The cockpit owns four core responsibilities, each defined below.

Multi-site visibility

Provides portfolio-level visibility across every site the account owns. Each site appears as a card in the Dashboard with its current operational state, last-modified hint, and entry into per-site work. An operator running ten sites sees ten cards; an operator running one site sees one card. The shape is the same.

Provisioning entry

Acts as the main command surface for site creation, setup routing, and capacity-aware account actions. Adding a site is an account-tier event — the new site lands under the existing account, inherits the plan tier, and routes into setup completion through the same Dashboard surface.

Billing and capacity access

Owns subscription-state visibility and routes operators into capacity, subscription, and billing recovery flows. Billing is account-tier — one subscription can cover many sites; renewal, payment method, and invoice history are managed once at the Dashboard rather than once per site.

Operational routing

Routes operators into site settings, integrations, locations, reporting, and related account-level workflows. The Dashboard does not own the deep work; it owns the surface from which deep work begins.

Key elements

SG-Dashboard should be understood through the kinds of operational areas it exposes rather than as a single-purpose screen.

Dashboard control surfaces

Entry points for account-level actions, operational summaries, and guided setup paths. These surfaces are the reason an operator opens dashboard.sgen.com in the first place — they show what needs attention at the account level and route into the work that addresses it.

Site Manager

Site-card based control surface for access, setup continuation, site settings entry, and site-level operational actions. Site Manager is the panel where every site the account owns is listed and where most cross-site routing originates.

Billing surfaces

Subscription, capacity, and account-state views that determine whether further provisioning or access is available. Billing surfaces also include payment method management, invoice history, and the recovery flows for billing-related lockouts (capacity exhaustion, expired card, failed renewal).

Integration and settings entry points

Routes into per-site settings, Google integrations, locations, and other configuration-aware account paths. The Dashboard is the entry point; the deep configuration runs at the site tier.

Reporting entry points

Account-level access into report-generation and related visibility workflows. Reporting at the Dashboard is portfolio-shaped — multi-site rollups, account-wide summaries, comparative views — while per-site reporting detail lives further down in the admin Analytics surface.

Operational role

Operationally, SG-Dashboard is the portfolio command layer of SGEN. It is where account owners and operators manage site-level readiness from above the site itself.

It does not replace SG-Admin for site administration. It does not replace SG-Builder for layout composition. Instead, it coordinates entry into those deeper surfaces — and owns the operations (billing, multi-site reports, support routing, account invitations) that genuinely belong at the account tier.

In daily operator use, an account that runs one site sees the Dashboard as a familiar landing page that surfaces the next thing to do on that site. An account that runs many sites sees the Dashboard as the routing layer for the day — open this site's SG-Admin to fix a setting, open that site's SG-Admin to publish a page, open the Billing surface once a quarter to confirm the renewal, open Reports once a week to scan portfolio performance.

Dependencies and related surfaces

SG-Dashboard should be read in relation to the product surfaces and system areas it connects.

SG-Admin

Site-specific administration continues in the admin after Dashboard routing, access, or setup entry has occurred. The Dashboard hands off to the admin via the site card; from there, all site-tier work — content, modules, settings, configuration — happens in the admin pillars.

SG-Builder

Visual composition remains outside the Dashboard layer and is handled in SG-Builder once work moves into presentation editing. SG-Builder is opened from inside the admin via the Edit with SG Builder action on any editable record (Page, Post, Product, Custom Object) — never directly from the Dashboard.

Workflows and Integrations

Many cross-product workflows begin in SG-Dashboard and continue into integrations, reporting, settings, or downstream operations. Google Integrations, Locations, and Site Settings configuration are all anchored at the account tier and applied at the site tier.

Migration and Import

Backup, restore, and migration-aware operations have their account-tier index in the Dashboard's Site Manager (so the operator can see every site's backup history in one place) but execute at the site tier (because each site has its own backup snapshot).

Constraints and boundaries

SG-Dashboard is an account-level and multi-site control surface. It should not be treated as the primary location for site-content administration or visual page building.

Use SG-Dashboard for:

• Portfolio control across every site the account owns.
• Provisioning a new site under the account.
• Billing, subscriptions, payment methods, invoices.
• Multi-site reporting and analytics rollups.
• Inviting users to administer one or more sites.
• Support tickets — tickets are scoped to the account, not any one site.
• Site Manager actions: maintenance mode, backup index, site setup continuation.

Use SG-Admin for:

• Site-level records, content, modules, store, and operational control panels.
• Per-site settings, theme, custom codes, custom fonts.
• Per-site users, permissions, and editorial workflows.

Use SG-Builder for:

• Page-level layout composition and visual editing.
• Section composition, component arrangement, theme-aware styling at the page level.

Use Guides for:

• Procedures and task-by-task execution rather than surface definition.

Public boundary

This page is intentionally public-safe. It does not expose private infrastructure detail, internal credentials, exact network topology, unpublished operational controls, or protected service identifiers. Architectural depth lives in Architecture and Reliability and the per-area Reference pages, all written to the same public boundary.

Boundary at a glance

The boundary between SG-Dashboard, SG-Admin, and SG-Builder is intentional. When the surface answers a question about an account, a portfolio, a subscription, or which-site-do-I-open-next, the answer lives in SG-Dashboard. When the surface answers a question about a single site's records, content, or settings, the answer lives in the admin. When the surface answers a question about how a single page looks, the answer lives in SG-Builder. Operators who internalize the boundary stop guessing where to start and stop wasting clicks navigating from the wrong tier.

The boundary also explains why a feature appears on one surface and not on another. Multi-site reporting belongs on the Dashboard because it is portfolio-shaped; per-site reporting belongs on SG-Admin because it is single-site-shaped; in-page analytics annotations belong on SG-Builder because they are page-shaped. Each tier carries a clear shape, and features land on the tier whose shape matches the feature's shape.

That principle holds across every Dashboard responsibility area, every Site Manager action, and every cross-surface routing path documented in the rest of the SG-Dashboard sub-pages.

Examples

Example 1 — A new operator opens SG-Dashboard for the first time

The operator lands at dashboard.sgen.com, sees one site card for the site they own, and recognizes the layout immediately — current operational state, quick actions, entry into Site Manager. They click into the site card, land in the admin for that site, and start the setup-completion guide. The Dashboard did its job by routing them cleanly into the per-site work without making them learn a separate cockpit shape.

Example 2 — An agency principal manages a portfolio of fifteen client sites

The agency principal lands at SG-Dashboard, sees fifteen site cards, scans for the one with a maintenance-mode indicator. They click into Site Manager for that site, take the site out of maintenance after confirming the editorial work is done, and route back to Dashboard to scan the rest of the portfolio. Their next visit to the cockpit is to reconcile the monthly billing — one Billing panel covers every site under the account, so reconciliation is a single-place operation rather than fifteen.

Example 3 — A support operator triages a billing-related lockout

A support operator opens SG-Dashboard for a customer account where the billing surface is showing a failed-renewal indicator on the Subscriptions panel. The Dashboard's Billing recovery flow walks the operator into payment method update, retry, and confirmation. The site itself never needs to be opened in the admin — the lockout is account-tier, the recovery is account-tier, the Dashboard owns both ends of that operation.

Documentation guidance

Use this page as a stable Reference definition. The shape on this page should remain consistent across releases — feature additions land inside one of the existing responsibility areas (multi-site visibility, provisioning entry, billing access, operational routing) rather than as a new top-level Dashboard category.

Procedural instruction belongs in Guides; shipped updates and release-specific changes belong in What's New or Changelog. Per-area capability detail (Site Manager interior, Billing interior, Analytics interior, Client Manager interior, Integrations interior) lives in the corresponding sub-pages, not here.

When you write or review a new Dashboard sub-page, anchor it under one of the responsibility areas defined here. When you write or review a new Guide that touches the Dashboard, link back to this page as the Reference definition the Guide assumes.

Related reading

• Platform Overview — the system map across the three operating surfaces.
• Site Manager — the site-card cockpit inside SG-Dashboard.
• Billing Overview — account-level subscription, capacity, and payment surface.
• Analytics — multi-site reporting and analytics rollups.
• Client Manager — agency and multi-account management surface.
• SG-Admin Overview — the site administration layer that SG-Dashboard routes into.
• Architecture and Reliability — the architectural framing for the platform that SG-Dashboard sits on top of.

Fields

Where to find it

Open your SG-Admin and navigate via the sidebar group that owns this surface. For platform-level reference (this page), the entry point is the SGEN documentation index at docs.sgen.com. For the operator-facing configuration screen, the entry point is the corresponding SG-Admin module page linked in Related features above.