SG-Admin

The site administration layer — content, modules, store, settings, and configuration for one site.

SG-Admin lives at {site-domain}.com/sg-admin/ for each site under your account. It is the operator surface where the site's records, content, modules, settings, and operational configuration live. SG-Builder, the visual page composer, is embedded inside the admin and opened from any editable record (Page, Post, Product, Custom Object) via the Edit with SG Builder action.

This page is the Reference definition of the surface. It explains what SG-Admin owns, the module families it exposes, how it differs from SG-Dashboard (account-tier) and SG-Builder (page-tier), and how it should be read inside the wider SGEN operating model.

What is this for?

Read this page when you want the structural definition of SG-Admin — what surface it is, where it sits in the platform model, what kinds of operations belong here versus higher in SG-Dashboard or deeper in SG-Builder, and what the module families look like at a glance. It is the entry-point Reference for everything else inside the admin section.

The page is a Reference definition. It does not walk you through a procedure. Step-by-step procedures live in Guides. Per-area capability detail lives in the admin sub-pages (Pages, Blogs, Media Library, SEO, Forms, Locations, Products, Orders, Tools, etc.).

Good use cases

• You are new to the platform and want to understand what /sg-admin/ is for before opening any module.
• You are explaining to a stakeholder or operator what SG-Admin owns versus what SG-Dashboard owns versus what SG-Builder owns.
• You are scoping a per-site rollout and need the module inventory to plan editorial workflows.
• You hit an action somewhere in the platform and want to confirm whether it belongs in the admin or in another tier.
• You are planning a site migration and need to see which SG-Admin modules cover which kinds of imported records.

What NOT to use this for

• Step-by-step procedures — open the relevant Guide.
• Per-module capability detail — open the corresponding SG-Admin sub-page.
• Account-tier operations (billing, multi-site reporting, support tickets) — open SG-Dashboard.
• Visual page composition — open SG-Builder via the Edit with SG Builder action on a record.
• 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 placing SG-Admin inside the three-surface model.
• SG-Dashboard Overview — the account-tier surface that routes operators into the admin.
• SG-Builder Overview — the visual editor embedded inside the admin.
• Shared Concepts — the cross-platform models SG-Admin modules depend on.
• Per-module Reference pages (Pages, Blogs, Media Library, SEO, Forms, Locations, Products, Orders, Tools, Migration) — the deep detail per administrative area.

Definition

SG-Admin is the site administration layer in SGEN. It provides structured site administration for content, modules, commerce, utilities, and operational configuration. It owns record management, settings, and control panels that affect site behavior, and it works alongside SG-Builder, which handles visual composition rather than administrative structure.

Where SG-Dashboard owns the portfolio across every site the account holds, SG-Admin owns the records inside one specific site. The two surfaces are paired: SG-Dashboard routes operators into the admin via the site card; SG-Admin then exposes the modules that govern what the site contains and how it behaves.

The defining property is scope. SG-Dashboard is account-tier (multi-site). SG-Admin is site-tier (single-site). SG-Builder is page-tier (single page inside the active site). Each tier has a clear shape, and the boundary between them is what keeps the operating model legible at scale.

Purpose

The purpose of this page is to define SG-Admin as the primary site-level administration surface in the SGEN platform. It establishes the kinds of administrative responsibility that belong here, clarifies how SG-Admin differs from SG-Dashboard and SG-Builder, and provides a stable reference point for reading the rest of the admin library.

Scope

This page covers SG-Admin at the Reference level. It defines the administrative role, scope, and structural coverage of SG-Admin as a whole. It does not document step-by-step operations for each module — those live in the per-module Reference and Guide pages.

The page covers:

• The site-level administrative role of SG-Admin.
• The module families that make up the surface.
• The boundary against SG-Dashboard (account-tier) and SG-Builder (page-tier).
• The dependencies on Shared Concepts, Workflows, Migration and Import.
• The constraints that keep site-tier work cleanly separated from account-tier and page-tier work.

The page does not cover:

• Per-module capability detail — per-module Reference pages.
• Per-area procedures — Guides.
• Account-tier operations — SG-Dashboard Reference.
• Visual page composition — SG-Builder Reference.
• Per-customer infrastructure detail — Infrastructure Overview or support escalation.

Responsibilities

SG-Admin is responsible for the administrative layer of an individual site. It concentrates operational control into a governed structure instead of scattering site management across unrelated surfaces.

Record administration

Owns inventories, detail views, creation flows, moderation surfaces, taxonomy management, and module-level records across site content and operational objects. Pages, Blogs, Products, Orders, Forms, Custom Objects, Locations, Events — every persistent record the site holds is administered from inside the admin.

Settings and configuration

Owns site-level settings, defaults, policies, and control panels that influence downstream behavior rather than one isolated object only. Site identity, social links, email configuration, theme registration, custom code surfaces, custom fonts, redirects — anything that defines how the site behaves at the platform level lives in the admin Configuration pillar.

Operational visibility

Provides administrative visibility into the selected object type or module and serves as the entry point into follow-on tasks such as editing, publishing, moderation, reporting, migration, or configuration review. The administrative views in the admin are not lists — they are the working surface for the editorial and operational team.

Key elements

The SG-Admin section includes a broad set of administrative areas. The current Reference library lists the following top-level module families:

Each module is a self-contained administrative area. The Reference page for each module defines what it owns, what it routes into, and how it relates to its peers. This SG-Admin Overview page is the entry point; the per-module Reference pages are the deep detail.

Operational role

Operationally, SG-Admin is the persistent system-of-record surface for site administration. It is where the site's structured administrative state is created, reviewed, updated, and controlled. Inventory views, add-new surfaces, module settings, and configuration pages all exist here because they change site behavior in durable ways rather than providing temporary or portfolio-level visibility.

In daily operator use, SG-Admin is the surface an editorial or operations team opens for most working hours. Account-level work happens occasionally at SG-Dashboard (billing reconciliation, new-site provisioning, multi-site reports). Visual layout work happens occasionally at SG-Builder (page composition during editorial cycles). The day-to-day work — content updates, store fulfilment, settings adjustments, moderation, configuration tuning — happens at SG-Admin.

Dependencies and related surfaces

SG-Admin should be read in relation to the surrounding product surfaces and system areas it depends on or hands work off to.

SG-Dashboard

The account-tier surface that routes operators into the admin via the site card. Operators arrive at SG-Admin from SG-Dashboard for most cross-site context switches.

SG-Builder

The visual page composition environment, embedded inside the admin and opened from any editable record (Page, Post, Product, Custom Object) via the Edit with SG Builder action. SG-Admin owns the record; SG-Builder owns the page-level layout for that record.

Shared Concepts

The cross-platform rules and models that SG-Admin modules depend on across content, configuration, governance, and site context. Shared Concepts is the conceptual backbone every SG-Admin module assumes.

Migration and Import

Migration-sensitive activity often becomes visible or manageable in the admin because imported records, settings, and site state are administered here after handoff. The Migration pillar inside the admin is the per-site working surface for migration operations.

Workflows and Automation

Workflows define cross-product process flows that pass through the admin (publishing, moderation, escalation). Automation defines background and scheduled behavior that affects site state outside the operator's direct interaction.

Constraints and boundaries

SG-Admin is a site administration surface. It should not be treated as the portfolio control layer or as the primary visual composition environment.

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.
• Per-site configuration, tools, and migration operations.

Use SG-Dashboard for:

• Account-level and multi-site operations (billing, provisioning, multi-site reporting, support).

Use SG-Builder for:

• Layout composition and presentation editing inside a single page.

Use Guides for:

• Procedural instruction rather than surface definition.

Public boundary

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

Boundary at a glance

SG-Admin handles persistent site state. SG-Dashboard handles account portfolio. SG-Builder handles page layout. Operators who internalize the boundary stop guessing where to start and stop wasting clicks navigating from the wrong tier. Features land on the tier whose shape matches the feature's shape.

Examples

Example 1 — Editor publishes a new blog post

The editor opens SG-Dashboard, clicks into the relevant site card, lands in the admin. They open the Blogs module, click Add New, fill in the post metadata, then click Edit with SG Builder to compose the post body visually. They publish from inside SG-Builder. The records administration happened in the admin (Blogs module); the visual composition happened in SG-Builder; the publish action happened from SG-Builder back into the admin record state.

Example 2 — Operator adjusts site-wide SEO defaults

The operator opens the admin → Configuration → SEO. They adjust the site-wide title and meta defaults, save, and confirm the change has propagated to public pages. The work is site-tier (this site's SEO defaults), happens in the admin (configuration surface), and does not require either SG-Dashboard or SG-Builder. SG-Admin owns the full operation.

Example 3 — Migration operator imports a content batch

The migration operator opens the admin → Migration. They run an import using the Migration pillar tools, validate the imported records via the Pages and Blogs modules, and adjust any settings that need post-migration tuning. Cross-module work happens entirely inside the admin because every import-related surface lives here.

Example 4 — Store operator configures a coupon and reviews orders

The store operator opens the admin → STORE MANAGEMENT → Coupons, configures a percentage discount with an expiry, then moves to Orders to scan recent transactions and confirm none have been affected by the upcoming change. Both modules sit inside the same pillar; the operator never leaves SG-Admin for store work. Per-product visual layout, when needed, is handed off to SG-Builder by clicking Edit with SG Builder on the relevant Product record.

Example 5 — Agency operator adjusts site-wide custom code

The agency operator opens the admin → CONFIGURATION → Tools → Custom Codes and adds a site-wide tracking snippet under the page-scoped CSS surface. They confirm the snippet renders on the live site without affecting other sites under the same account. The work is site-tier (this site's custom code), happens in the admin (Custom Codes surface), and remains scoped to one site even though the operator's account holds many.

Documentation guidance

Use this page as a stable Reference definition. The shape on this page should remain consistent across releases — module additions land inside one of the existing pillars (GENERAL, MODULES, STORE MANAGEMENT, CUSTOM OBJECTS, CONFIGURATION) rather than as a new top-level pillar.

Procedural instruction belongs in Guides; shipped updates and release-specific changes belong in What's New or Changelog. Per-module capability detail lives in the corresponding Reference sub-pages, not here.

When you write or review a new SG-Admin module Reference, anchor it under the correct pillar and link back to this page as the entry-point Reference the module sits under.

Pillar discipline at a glance

The five-pillar shape (GENERAL · MODULES · STORE MANAGEMENT · CUSTOM OBJECTS · CONFIGURATION) is intentional. Operators learn the pillars once and apply them across every site they administer. Module additions over time land inside an existing pillar rather than fragmenting the surface into more top-level entries. Reference pages, Guides, and Changelog entries should all anchor to the same pillar vocabulary so the surface remains legible as it grows.

The pillar discipline also makes the boundary against SG-Dashboard and SG-Builder easier to enforce. Records, settings, and per-site configuration belong inside one of the admin pillars by definition. If a feature does not fit any of the five pillars, that is the signal it belongs at a different tier — most often SG-Dashboard for portfolio operations or SG-Builder for page-level layout work.

Reading order across the section

Open the admin Overview (this page) first to anchor the model. From there, descend into the per-module Reference pages in the order that matches your work — Pages and Blogs for editorial teams, Products and Orders for store operators, Configuration and Tools for site administrators, Migration for handoff and import work. The Reference pages can be read in any order; this Overview page is the structural assumption every per-module page leans on.

Once the per-module Reference pages are anchored, the Guides for those modules layer on top — procedural detail per task, with each Guide assuming the Reference is already understood. The pairing keeps the documentation legible: Reference for what the surface IS, Guides for what the operator DOES on that surface.

Where to find it

In SGEN Admin, navigate to {site-domain}.com/sg-admin/ for any site under the account. From SG-Dashboard, click the site card to land directly in that site's SG-Admin. The sidebar exposes the five pillars — GENERAL, MODULES, STORE MANAGEMENT, CUSTOM OBJECTS, and CONFIGURATION — each with its own module entries.

Where SG-Admin appears on the live docs site

The SG-Admin section in docs.sgen.com mirrors the same pillar shape documented here. Top-level navigation lands on this Overview page; the per-module Reference and Guide pages descend from there. Cross-links between SG-Admin Reference, SG-Admin Guides, SG-Dashboard, SG-Builder, Shared Concepts, and Architecture and Reliability follow the boundary discipline laid out in this page.

Related reading

• Platform Overview — the system map across the three operating surfaces.
• SG-Dashboard Overview — the account-tier surface that routes into the admin.
• SG-Builder Overview — the visual editor embedded inside the admin.
• Shared Concepts — cross-platform models the modules depend on.
• Architecture and Reliability — the architectural framing for the platform that SG-Admin runs on.
• Workflows Overview — cross-product process flows that touch SG-Admin.
• Automations Overview — background and scheduled behavior that affects site state.
• Integrations Overview — third-party systems that connect into the admin modules.
• Migration and Import Overview — import, backup, validation, and recovery operations.

Vocabulary cross-reference

• SG-Admin is the canonical surface name for site administration. Internal docs may abbreviate to "Admin" in body copy; surface naming stays "SG-Admin".
• Pillar refers to one of the five top-level groupings (GENERAL, MODULES, STORE MANAGEMENT, CUSTOM OBJECTS, CONFIGURATION).
• Module refers to a single administrative area inside a pillar (Pages, Blogs, Products, Forms, etc.).
• Site context is the operating context bounded by {site-domain}.com/sg-admin/... — distinct from account context bounded by dashboard.sgen.com/....