SGEN Platform — overview

How the four product surfaces fit together as one operating platform.

SGEN is a single platform composed of four product surfaces — SG-Core, SG-Modules, SG-Dashboard, and SG-Builder — that share data, settings, and identity but serve different operator workflows. Knowing where a workflow lives shortens the time from "I need to do X" to "I'm doing X."

This page is the platform-level orientation read. It names the four surfaces, explains the relationships, and points at the canonical reference for each.

What is this for?

Use this page as the first stop when you need to know which SGEN surface owns a workflow. It maps the four product surfaces to the operator workflows they cover and the data they share.

The platform overview is intentionally narrow — it does not document any single surface in depth. For deep coverage of each surface, follow the links to its dedicated reference page.

Good use cases

• You're new to SGEN and want a one-page orientation before diving into specific surfaces.
• You know a workflow exists somewhere in SGEN but you're not sure which surface owns it (admin? dashboard? builder?).
• You're evaluating SGEN and want to understand the platform's shape before testing any single feature.
• You're onboarding a teammate and want them to see how the surfaces relate before they specialize in one.
• You're explaining SGEN to a stakeholder who needs the structural picture, not the per-feature detail.

What NOT to use this for

• Step-by-step instructions for any specific feature — open the surface-specific reference page for that.
• Pricing or plan-tier breakdowns — that lives in account / billing reference, not platform reference.
• Setup wizard walkthrough — open SGEN Setup Wizard for first-install steps.
• Build instructions for pages — open the SG-Builder reference for the canonical page-build sequence.

How this connects to other features

• SG-Core — the platform spine. Settings, users, billing, authentication, identity. Every other surface depends on Core decisions made here.
• SG-Modules — the modular capabilities. Forms, blog, popups, locations, custom objects, events, fonts. Each module is independently enabled and configured.
• SG-Dashboard — analytics, reporting, site health, and admin-side observability. Pulls data from Core + Modules and presents it as actionable insight.
• SG-Builder — the page-build surface. Visual page composition with components, design tokens, and the canvas. Stores its output in pages owned by Core.
• Setup Wizard — the first-install flow that bootstraps SG-Core identity and chooses a starting theme.
• Getting Started with SGEN — operating-model orientation, broader than this surface map.

Where to find each surface

The four surfaces are accessed from the admin sidebar at /sg-admin/:

• SG-Core surfaces live under the sidebar's GENERAL section (Settings, Users, Site Settings).
• SG-Modules live under the MODULES section (each module has its own sidebar entry).
• SG-Dashboard is the landing screen at /sg-admin/ itself, plus the dedicated SG-Dashboard at dashboard.sgen.com for account-level views.
• SG-Builder opens from any page edit screen via the Edit with SG-Builder action, or via the URL pattern /sg-admin/pages/edit/<id>?action=sgbuilder.

Each surface has its own admin chrome and conventions, but the same SGEN identity (logo, brand, navigation) wraps all of them.

The four surfaces in detail

1. SG-Core — the spine

SG-Core owns the foundational data on every SGEN site:

• Site identity — name, description, logo, favicon, contact info.
• 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.

When you change something in SG-Core, the change ripples through every other surface. The site title set in SG-Core appears in the browser tab, in SG-Builder previews, in SG-Dashboard widgets, in SG-Module email-from headers. One source, many readers.

2. SG-Modules — the capabilities

SG-Modules are the discrete feature capabilities you can enable per site:

• Forms — capture leads, contact, custom data; routes submissions to integrations.
• Blog — posts, categories, tags, scheduling, comments.
• Popups — overlays with triggers and targeting.
• Locations — multi-location data, visitor selector, per-location content adaptation.
• Custom Objects — bespoke data types beyond pages and posts.
• Events — calendar entries, RSVPs, event archives.
• Custom Fonts — typography uploads outside the default stack.

Each module is configured independently. Enabling Blog does not affect Forms; disabling Locations does not break Popups. Modules read identity and user data from SG-Core but otherwise stand alone.

3. SG-Dashboard — the operator view

SG-Dashboard is where the operator reads the site's state:

• Site Vitals — Lighthouse-style scoring across performance, accessibility, best practices, SEO.
• Leads Overview — counts and trends from the Forms module.
• Lead Sources — traffic attribution across organic, direct, referral, paid.
• SEO Overview — page counts, items needing work, indexing health.
• Recent Activity — what changed on the site recently.

SG-Dashboard does not author content. It reads from SG-Core, SG-Modules, and the public site, then presents the synthesis. There's also a separate dashboard.sgen.com surface for account-level views (multi-site customers, billing, support tickets).

4. SG-Builder — the page builder

SG-Builder is the visual page composition surface:

• Drag-and-drop component canvas (heroes, sections, cards, testimonials, CTAs, products, posts archives, custom).
• Design tokens that propagate from site-level globals to every component.
• Responsive breakpoints (1920 / 1199 / 991 / 767 / 575 / 480).
• Component-scoped styles + global theme styles, with cascade conflicts surfaced as warnings.
• Save / publish flow that writes back to SG-Core as the page record.

SG-Builder pages are real pages owned by SG-Core's pages table. Editing a page in SG-Builder is editing the same page that shows in the Pages list and powers the public URL.

Steps — choose a surface for your workflow

Use this quick decision flow to pick the right surface:

1. "I need to change site identity, settings, or user access"

Open SG-Core surfaces — Settings, Users. Anything that affects the whole site lives here.

2. "I need to add or configure a specific capability"

Open the matching SG-Module — Forms / Blog / Popups / Locations / Custom Objects / Events / Custom Fonts. Each module has its own admin sidebar entry.

3. "I need to see how the site is performing or what visitors are doing"

Open SG-Dashboard — the landing screen at /sg-admin/ shows the per-site dashboard, and dashboard.sgen.com shows account-level views.

4. "I need to compose or edit a page visually"

Open SG-Builder — from any page row in the Pages list, click Edit with SG-Builder. The canvas opens with the live page state.

5. "I'm not sure which surface owns my workflow"

Search the docs from the global search bar at the top of any docs.sgen.com page. Each reference article is tagged with the surface that owns the workflow.

What success looks like

You know the platform layout when you can answer "where do I go to do X?" in under five seconds for any common workflow. A few examples:

• "Change the site logo." → SG-Core → Site Settings → General.
• "Add a popup that fires on exit intent." → SG-Modules → Popups → Create.
• "See which pages are slow on mobile." → SG-Dashboard → Site Vitals.
• "Change the hero on the homepage." → SG-Builder → open /home → Edit.
• "Add a team member with Editor access." → SG-Core → Users → Add New.

When all five answers land quickly, the platform has clicked. The detail of each surface is in its dedicated reference page — this overview keeps you oriented.

What to do if it does not work

The platform overview itself doesn't fail in the traditional sense — but here are the questions that come up most when operators are figuring out platform layout:

• I cannot find a workflow I expect to exist. Use the docs search bar at the top of docs.sgen.com — every reference article is tagged with its surface. If the workflow truly does not exist, the search returns no result, which is also useful information.
• A workflow appears in two surfaces. Some workflows have natural overlap — for example, you can edit a page from the Pages list (SG-Core) or open SG-Builder for the same page (SG-Builder surface). Both routes lead to the same underlying data; pick the one that fits your task.
• I clicked SG-Builder and got a different editor than I expected. Each page can use either SG-Builder or a fallback page editor. Check the page's template assignment in Site Settings; SG-Builder applies to pages that use a builder-compatible template.
• The SG-Dashboard widgets all show zero. Fresh-install state is correct for the first day. Site Vitals needs at least one scan; Leads Overview needs at least one form submission; Lead Sources needs at least one analytics-connected day. Connect Google Analytics from Tools → Google Integrations and trigger an initial scan.
• A SG-Module is missing from my admin sidebar. Modules can be enabled or disabled per site from the Modules configuration screen. If your plan tier excludes a module, the sidebar entry won't appear.

How the four surfaces share data

The shared-data layer is what makes SGEN feel like one platform instead of four products bolted together. Worth knowing how the data flows:

• Identity flows down from SG-Core. Site name, admin email, time zone, business address — set once in SG-Core, read by every other surface. Change the site name in SG-Core and the SG-Dashboard greeting updates, the SG-Module email-from line updates, the SG-Builder header preview updates.
• Content lives in SG-Core's record store. Pages and posts are SG-Core records. SG-Builder edits them visually; the Pages list in SG-Core admin shows them in a table. Same record, two views.
• Module data lives in SG-Modules but renders through SG-Builder and the public site. Forms render via the Forms module on any SG-Builder page that includes a Form component. Popups overlay any page when their trigger fires. Locations adapt content for the visitor's selected location.
• SG-Dashboard reads everything but writes nothing. It is a presentation layer over Core + Modules + public-site signals. Edits never originate at the dashboard — they originate at the surface that owns the data.

This separation keeps each surface focused. SG-Core never has to know how a popup is composed; SG-Builder never has to know how forms route submissions. The contract between them is the shared data, not a tangle of coupling.

Examples

Three short scenarios for how the four-surface model plays out in practice.

Example 1 — new operator orients on first day.

A new operator signs in to a fresh SGEN site. They open Settings (SG-Core), set site identity in 5 minutes — site name, time zone, admin email, business address. They open the Pages list (SG-Core's data) and click into the homepage row. The page opens in SG-Builder; they edit the hero, swap the placeholder copy for real brand language, and publish. They open SG-Modules → Forms and create a contact form; they drop it onto the contact page via the Form component in SG-Builder. They submit a test form themselves, then open SG-Dashboard to confirm the submission registered in Leads Overview. Four surfaces touched in one cohesive workflow. Total time: 20 minutes. The operator now has a working mental model of the platform.

Example 2 — agency hands off a built site.

The agency completes the build using mostly SG-Builder for pages and a small set of SG-Core settings. They configure SG-Modules → Forms with the client's submission routing (Slack channel for sales leads, a shared inbox for general contact). They walk the client through SG-Dashboard so the client can read their own analytics and Site Vitals scores. They transfer SG-Core's admin user to the client by adding the client as Administrator, then trashing the agency's user. The handoff is clean because each surface has a clear ownership boundary — the client knows where to go for which workflow without needing the agency on standby.

Example 3 — operator troubleshoots a missing feature.

An operator asks "where are my newsletter signups going?" They check SG-Modules → Forms (the form definition is there with the right fields). They check SG-Dashboard → Leads Overview (counts look correct, the signups ARE being captured). They realize the question isn't about counts — it's about routing. They open SG-Modules → Forms → integration settings and confirm the Mailchimp connector is wired up. The four-surface model surfaces the actual answer in two clicks: forms module owns submission routing, dashboard only reads counts. If the operator had searched SG-Dashboard for the routing answer, they would have spent 10 minutes finding nothing — the platform shape told them which surface to ask.

Tips for working across surfaces

A few habits keep work flowing cleanly across the four-surface boundary:

• Start every new site with SG-Core identity first. Site name, admin email, time zone, business address. Setting these once at the start avoids three rounds of fixing downstream displays — the SG-Builder header preview, the SG-Module email-from line, the SG-Dashboard greeting all read from the same Core record.
• When in doubt, search docs.sgen.com. Every reference article is tagged with the owning surface. Searching by feature name routes you to the right surface faster than guessing.
• Don't replicate data across surfaces. If business hours change, edit them in SG-Core (Site Settings → General) — every surface that displays hours reads from there. Don't paste hours into a page in SG-Builder; that turns one Core record into N hard-coded duplicates that drift over time.
• Use SG-Dashboard as the daily read. Open it at the start of each session to see Site Vitals, Leads, and Recent Activity at a glance. It's the lower-cost way to spot anomalies — a drop in Leads, a slow page in Vitals, a stale activity feed.
• Treat SG-Builder pages as canonical brand surfaces. Header, footer, and key landing pages get the most visitor attention. Edit them deliberately in SG-Builder; review at multiple breakpoints; preview before publish.
• Configure SG-Modules incrementally. Don't enable every module on a fresh install. Enable Forms when you need a form. Enable Locations when you have multi-location data. The sidebar stays scannable when modules match actual usage.

Quick reference — which surface owns what

A condensed cheat sheet for the most common "where does X live?" questions:

• Site name, site description, contact info → SG-Core (Settings → General)
• Logo, favicon → SG-Core (Settings → General)
• Time zone → SG-Core (Settings → General)
• Admin users, roles, password resets → SG-Core (Users)
• Social media URLs → SG-Core (Settings → Social Media)
• Business hours, address, phone → SG-Core (Settings → General)
• Page content + page-level SEO → SG-Builder (page editor) for visual; SG-Core (Pages list) for metadata
• Blog posts, categories, tags → SG-Modules → Blog
• Forms, form submissions, integrations → SG-Modules → Forms
• Popups, triggers, targeting → SG-Modules → Popups
• Locations, visitor selector → SG-Modules → Locations
• Site analytics, traffic, SEO overview → SG-Dashboard
• Site Vitals score, performance scan → SG-Dashboard
• Account-level billing, multi-site, support → dashboard.sgen.com (separate from in-admin SG-Dashboard)
• Theme palette, typography, design tokens → SG-Builder (theme editor) or SG-Core (Appearance → Themes)
• Page templates, headers, footers → SG-Builder (template editor) + SG-Core (Templates list)
• Custom CSS, custom codes → SG-Core (Appearance → Custom CSS / Custom Codes)
• Maintenance mode, post revisions cleanup → SG-Core (Tools)

Plan tiers and surface availability

A few notes on which surfaces are available where:

• SG-Core is available on every SGEN plan tier. The basic identity, users, and settings are universal.
• SG-Modules availability varies by tier. Sandbox includes a baseline set (Forms, Blog). Growth and higher tiers unlock the remaining modules (Locations, Custom Objects, Events, Custom Fonts).
• SG-Dashboard site-level view is available everywhere. The account-level dashboard at dashboard.sgen.com is for multi-site customers and includes billing + support across sites.
• SG-Builder is available on every tier. The component library is the same across tiers; design tokens and theme presets ship with the site.

If a surface or module is missing from your admin sidebar, the most likely cause is plan-tier exclusion. Open Account Settings to confirm your current tier and what it includes.

Why one platform instead of four products

A common question from operators arriving from other platforms: why bundle four product surfaces under one roof instead of shipping them as separate tools?

Three reasons drove the architecture:

• One source of truth for identity and content. When the four surfaces share data, the operator never has to reconcile the site name across products, or sync user accounts between an admin and a builder. Edit once in SG-Core; every surface sees the change.
• One install, one billing, one place to learn. Bundling reduces the surface area an operator has to learn. The four surfaces share visual conventions (sidebar, top nav, buttons, modals) so familiarity in one transfers to the others.
• Modules can lean on Core invariants. SG-Modules know that user, site identity, and authentication are always present and consistent. They don't have to defensive-code around partial state.

The cost: each surface needs its own design discipline so the operator can tell which surface they're in. SGEN handles this by giving each surface a clear chrome — SG-Builder's canvas-and-panels layout, SG-Dashboard's widget grid, SG-Module admin's table-and-form pattern, SG-Core's settings forms. The pattern signals the surface; the data flows underneath.

The net effect: one platform that lets four surfaces specialize without making the operator feel like they're juggling four apps.

Related reading

• SG-Core reference — settings, users, identity surfaces.
• SG-Modules reference — module-by-module capability list.
• SG-Dashboard reference — dashboard widgets and account-level views.
• SG-Builder reference — page builder canvas and component model.
• Setup Wizard — the first-install flow.
• Getting Started with SGEN — broader orientation guide for new operators.

Scope

This Reference covers the platform-level shape of sgen platform overview: what the surface is responsible for, how it relates to neighboring surfaces, and the structural boundaries that hold across releases. Operator how-to and per-release change land on the linked operator-facing or changelog surfaces, not here.

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.