Platform Overview

The 60-second answer. SGEN is built on one foundation (SG-Core) with three operating surfaces on top: SG-Dashboard (your account home — billing, site list, multi-site reporting at dashboard.sgen.com), SG-Admin (run one site day-to-day at yoursite.com/sg-admin/ — content, modules, settings), and SG-Builder (the visual page editor, embedded inside SG-Admin). Account-level work lives in SG-Dashboard; per-site work lives in SG-Admin; page layout lives in SG-Builder. The browser address bar is the fast tell: dashboard.sgen.com = account context; yoursite.com/sg-admin/ = site context.

That's the gist — everything below is the same idea in depth.

On this page: The three surfaces · Responsibility model · Boundary rules · Reference hierarchy · Reading model · Examples

This is the system map for the SGEN Reference library. Read it once before opening any deeper section — it establishes the structural frame that every other page assumes.

Platform Surfaces

The platform is structured around three primary operating surfaces and five supporting reference areas. Surfaces are separated by responsibility and connected by shared concepts, workflows, automation, integrations, and migration-aware operations.

The three primary surfaces

SG-Dashboard — the multi-site command layer

Lives at dashboard.sgen.com. One per customer organization. The account-level cockpit.

• Lists every site the account owns. Each site card opens that site's SG-Admin.
• Owns account-level operations only: Site Manager, Billing, Subscriptions, Payment Methods, Invoices, Support tickets, Owner Dashboard, multi-site reporting and analytics rollups.
• Cannot change the content of any one site from here. Click into a site card to switch into site context.
• Authentication is account-level — one login covers every site under the account.

SG-Admin — the site administration layer

Lives at {site-domain}.com/sg-admin/ for each owned site. The operator surface for that single site.

• Owns site-level content, modules, store, settings, and configuration.
• Five pillars: GENERAL, MODULES, STORE MANAGEMENT, CUSTOM OBJECTS, CONFIGURATION. Twenty-six tools across the pillars.
• Embeds SG-Builder. Open the visual editor for any Page, Post, Product, or Custom Object via the Edit with SG Builder action.
• Authentication is site-level — operators can be granted access to one site without affecting others.

SG-Builder — the visual editing environment

Embedded inside SG-Admin. Opened from any editable record (Page, Post, Product, Custom Object) on the active site.

• Owns layout composition, presentation, and page-level visual assembly.
• Does not own structured administration, records, modules, or commerce — those stay in SG-Admin.
• Operates only inside the active site's context. There is no cross-site builder session.

SG-Core — the platform spine

The foundational data layer every surface reads from. You do not work in SG-Core directly — you work in the surfaces that sit on top of it.

• Site identity — name, description, logo, favicon, contact info. Changes here ripple into every surface.
• User accounts and roles — administrators, editors, customers, and the role permissions that gate access.
• Authentication — sign-in, password reset, two-factor where the plan supports it.
• Site settings — timezone, homepage choice, 404 page, social URLs, business hours.
• Billing identity — the link from your SGEN account to your subscription and invoices.

SG-Modules — the modular capability layer

First-party feature modules that expand what a site can do. Each module is independently enabled and configured per site.

Examples: Forms, Blog, SEO, Popups, Locations, Events, Custom Objects, Ecommerce. Modules appear in the SG-Admin sidebar under MODULES once enabled.

The five supporting areas

These areas surround the three operating surfaces and define the rules, behaviors, and connection points that hold the platform together:

Other surfaces (kept on record)

• docs.sgen.com — read-only customer documentation, the surface you are reading right now.
• the Changelog page — release ledger syndication.
• app.sgen.com — application host reference (engine origin); reference only.

Domain rule

SGEN owns one domain: sgen.com. Everything else is a subdomain. References to sgen.io, s10.com, or any other root are typos to be silently corrected.

Responsibility Model

The platform depends on clear boundaries between its operating surfaces. Each area has a distinct operational role. Place daily work at the surface that owns it the first time, and most of the "where did my change go?" confusion never starts.

Account context vs site context — the line that matters most

You are operating in account context when the address bar reads dashboard.sgen.com/.... Your changes affect billing, subscriptions, invitations, support tickets, and the list of sites under this account. You cannot change a single site's content from here.

You are operating in site context when the address bar reads {site-domain}.com/sg-admin/... or you are working in the SG-Builder editor on a page. Your changes affect that site's content, design, products, orders, and settings. They do not affect any sibling site under the same account, even when sibling sites share a theme or are run by the same operator.

The browser address bar tells you which context you are in. Switching between them is intentional — the dashboard does not reload "the same page" across sites; each site has its own admin.

Boundary rules — where each type of work lives

Surface ownership at a glance

• Dashboard responsibility — account-level and multi-site operational control. Provisioning entry, billing, portfolio visibility, reporting entry points, and routing into site-specific work.
• Admin responsibility — site-specific administration. Records, settings, modules, configuration, and operational control panels that affect the active site.
• Builder responsibility — layout composition, visual editing, and page-level presentation assembly on the active site.
• Supporting-system responsibility — Shared Concepts, Workflows, Automation, Integrations, and Migration and Import. They define the rules, behaviors, connections, and guarded operational models that the operating surfaces depend on.

Cross-surface shared data — the watch-out

Some data appears on more than one surface. Editing it on one surface changes it on the other. Edit at the canonical surface; do not edit shadows.

Editing the non-canonical view can shadow the canonical state and cause stale renders. The rule is one-direction: define at the canonical surface, consume at the others.

Reference Hierarchy

The Reference library is structured as a set of top-level sections with embedded subtrees. Open each section in the order presented to build the platform shape from system frame to surface to module.

Top-level Reference sections

• Platform Overview — this page. The system map.
• Shared Concepts — recurring rules, models, and terminology used across the platform.
• SG-Dashboard — the account-level cockpit, broken down by panel.
• SG-Admin — the site administration layer, broken down by pillar and tool.
• SG-Builder — the visual editor, broken down by surface and component.
• Workflows — cross-product process flows and handoff logic.
• Automation — background and scheduled behavior.
• Integrations — how third-party systems connect in.
• Migration and Import — import, backup, validation, and recovery.

What each Reference section contains

The SG-Admin Reference section, for example, expands into the twenty-six tools and twenty-three Appearance subtools that make up the operator surface — Appearance, Media Library, Blogs, Pages, Users, SEO, Discussions, My Forms, Phone Taps, Tracking Consent, Templates, Popups, Redirects, Custom Fields, Locations, Events, Analytics, Blacklist, Products, Orders, Coupons, Configuration, Custom Objects, Tools, and Migration.

Each Reference section is an entry point. The detail pages for individual tools and modules sit under that section, not under Platform Overview.

Reading Model

Read the Reference library from system-level structure to surface-level definition, then into subtrees and page-level references. The order matters: the structural frame on this page is the lens through which every other page makes sense.

Recommended reading order for a new SGEN administrator

1. Platform Overview (this page) — the platform shape.
2. Shared Concepts — recurring rules and terminology you will see referenced everywhere.
3. SG-Dashboard — the account-level cockpit so you know what lives at account tier.
4. SG-Admin — the operator surface so you know the pillars and tools available on each site.
5. SG-Builder — the visual editor so you understand what page composition looks like.
6. Architecture and Reliability — the architectural posture behind delivery, dependency, and change.
7. Guides — the first task you want to do.
8. What's New — subscribed for ongoing release awareness.

How the four documentation categories interact

How modules and child pages should be read

Module and child-page references should be read inside the context of their parent section, not as isolated documents. Open the parent section landing first, then descend.

How to use this page

Read it once — then use it as a reference when something feels misplaced. Cite it when onboarding a new admin or explaining the platform shape to a stakeholder.

Use this page for: system structure · ownership boundaries · reference hierarchy · onboarding context · cross-link anchor.

Not for: step-by-step procedures (open Guides) · module detail (open the module Reference page) · release history (open Changelog).

Examples

Example 1 — A new SGEN administrator opens the docs for the first time

The new admin reads Platform Overview to understand the platform is one foundation, three surfaces, and five supporting areas. They learn that billing lives at Dashboard, content lives at Admin, layout lives at Builder. They open Shared Concepts next for the recurring terminology, then SG-Admin to see the tools available on a single site. By the time they open the Pages Guide for the first time, every concept in that Guide already has a frame.

Example 2 — An agency operator scoping a multi-site rollout

The agency operator reads Responsibility Model to confirm that one Dashboard account can hold the multi-site portfolio they are scoping, with per-site Admin separation. They use the boundary rules table to plan which actions stay account-tier (billing, provisioning, multi-site reports) and which actions need per-site delegation (content, settings, theme). They link the Boundary Rules table into their internal scoping document so the client team knows which surface to operate from for each task.

Example 3 — A returning operator confirming the platform shape has not shifted

An operator returning after a quarter away opens Platform Overview to confirm the surfaces and supporting areas are unchanged. The structural model is the same — three surfaces, five supporting areas, the same Responsibility Model. They check Changelog for shipped feature changes and open Guides for any new procedures, but the system map on this page remains the anchor.

Related reading

• Architecture and Reliability — the architectural framing for delivery, dependency, and change.
• SGEN Product Definitions — companion page with the per-product responsibility deep-dive.
• SG-Dashboard Overview — the account-level cockpit deep-dive.
• SG-Admin Overview — the site administration layer deep-dive.
• SG-Builder Overview — the visual editing environment deep-dive.
• Shared Concepts — recurring rules and terminology used across the platform.
• Workflows Overview — cross-product process flows and handoff logic.
• Automations Overview — background and scheduled behavior.
• Integrations Overview — how third-party systems connect in.
• Migration and Import Overview — import, backup, validation, recovery, and migration-aware operations.