SG-Builder

The visual page editor — embedded inside the admin, opened from any editable record.

SG-Builder is the visual page editing environment used to compose and adjust page structure, blocks, and design settings. It is embedded inside the admin and opened from any editable record (Page, Post, Product, Custom Object) via the Edit with SG Builder action. SG-Builder owns layout and presentation at the page level; SG-Admin owns the record itself; SG-Dashboard owns the account-tier context above both.

This page is the Reference definition of the surface. It explains what SG-Builder is, how it relates to the admin and SG-Dashboard, what the editor model looks like at a glance, and where the publishing boundary sits.

What is this for?

Read this page when you want the structural definition of SG-Builder — what surface it is, where it sits inside the admin, what kinds of work belong here versus higher in the admin or SG-Dashboard, and how the editor surfaces (canvas, side panels, breakpoint switcher, publish action) hold together.

The page is a Reference definition. It does not walk you through how to build a page. Step-by-step procedures live in Guides. Per-component capability detail lives in the SG-Builder component reference.

Good use cases

• You are new to SGEN and want to understand what SG-Builder is for before opening it on a real page.
• You are explaining to a stakeholder or operator the boundary between record administration (SG-Admin) and visual layout (SG-Builder).
• You are scoping editorial workflows and need to know where the visual composition step sits in the publishing path.
• You hit an action somewhere in the platform and want to confirm whether it belongs in SG-Builder or in the admin.
• You are evaluating SGEN's editor model against a CMS-and-page-builder alternative and need the structural framing.

What NOT to use this for

• Step-by-step procedures for building a page — open the relevant Guide.
• Per-component capability detail — open the SG-Builder component reference.
• Record administration (Pages, Posts, Products, Custom Objects) — that lives in the admin.
• Account-tier operations (billing, multi-site reporting, support) — that lives in SG-Dashboard.
• Per-customer infrastructure detail — escalate to support.

How this connects to other features

• Platform Overview — the system map placing SG-Builder inside the three-surface model.
• SG-Admin Overview — the surface SG-Builder is embedded inside.
• SG-Dashboard Overview — the account-tier surface above SG-Admin.
• Shared Concepts — cross-platform models the editor depends on.

Definition

SG-Builder is the visual page editing environment in SGEN. It composes pages from blocks and components, applies design settings (typography, color, spacing, responsive behavior), and renders a preview state that matches what visitors will see on the live site.

SG-Builder is distinct from the admin in scope and purpose. SG-Admin manages records and configuration — what content exists on the site, how modules behave, what settings apply globally. SG-Builder manages visual layout, responsive presentation, and page-level composition for the record currently being edited.

SG-Builder is also distinct from SG-Dashboard. SG-Dashboard is the account-tier surface above the site; SG-Builder is the page-tier surface inside the site. The two never overlap — SG-Dashboard does not edit pages; SG-Builder does not manage portfolios.

Purpose

The purpose of this page is to define SG-Builder as the visual composition surface in SGEN, distinguish it from the admin and SG-Dashboard, and provide a stable Reference point for reading the rest of the SG-Builder library.

The page sits at the entry point of the SG-Builder section. Per-component, per-trait, and per-workflow detail lives in the deeper Reference and Guide pages; this page is the structural definition the rest of the section assumes.

Scope

This page covers SG-Builder at the Reference level — the surface as a visual composition environment rather than as a step-by-step build tutorial.

The page covers:

• The editor shell (canvas, side panels, breakpoint switcher, publish action).
• The record-edit entry point (Edit with SG Builder action on Page, Post, Product, Custom Object).
• The boundary against SG-Admin (record administration) and SG-Dashboard (account-tier context).
• The publishing model (explicit action, never a side effect).
• The dependencies on Shared Concepts, Workflows, and Architecture and Reliability.

The page does not cover:

• Per-component capability detail — component Reference pages.
• Step-by-step layout composition — Guides.
• Visual design tokens or theme configuration — that lives in the admin Appearance.
• Account-tier operations — SG-Dashboard Reference.

Editor model

SG-Builder exposes layout, block, page, and responsive controls inside a single editor shell. Operators work on a canvas that mirrors the rendered page; side panels surface block libraries, component traits, page settings, and the publishing action.

Canvas

The canvas renders the page being edited inside the active site context. It is the primary surface — most editing actions happen by clicking and adjusting on the canvas itself rather than by manipulating a separate property tree.

Block library

The block library exposes the available components for assembly into the page. Components are first-party and scoped — there is no plugin marketplace to draw from. The block surface is the same on every site under the same theme registration.

Trait panel

The trait panel surfaces the per-component configuration when a block is selected on the canvas. Traits include layout, decoration, content, behavior, and responsive overrides.

Breakpoint switcher

SG-Builder authors responsive behavior across the platform's standard breakpoints (1920 / 1199 / 991 / 767 / 575 / 480). The breakpoint switcher in the editor changes the canvas viewport so layout and presentation can be tuned per device.

Publish action

Publishing is explicit. The editor maintains an unpublished state until the operator clicks the publish action. The site does not auto-publish on every keystroke; the unpublished state can be reviewed, adjusted, or discarded before it becomes visible to end users.

Responsibilities

SG-Builder is responsible for the visual composition layer of an individual page. It owns three core responsibilities, each defined below.

Layout composition

Owns block selection, arrangement, and the structural shape of the page being edited. The editor produces a layout the platform can render server-side as part of the page delivery.

Responsive presentation

Owns the per-breakpoint adjustments that determine how the page looks across device widths. Responsive overrides are scoped to the page being edited; they do not bleed across pages or across sites.

Per-page presentation

Owns the typography, color, spacing, and decoration applied at the page or component level. Site-wide presentation defaults remain in the admin Appearance; per-page or per-component overrides happen in SG-Builder.

Operational role

Operationally, SG-Builder is the visual composition surface that sits inside the editorial cycle for any record that has a page-rendered output. Pages, blog posts, product detail pages, and custom-object detail pages all open in SG-Builder when the operator wants to compose or adjust the visual layout.

In daily operator use, SG-Builder is opened in shorter focused sessions — open a record, compose or adjust the layout, publish, close. It is not a surface most operators sit in for hours; it is a surface they enter, complete a defined unit of work in, and leave. The longer-running daily work — content updates, store fulfilment, settings adjustments — happens in the admin.

Dependencies and related surfaces

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

SG-Admin

The administrative surface SG-Builder is embedded inside. SG-Admin owns the record being edited; SG-Builder owns the layout for that record. The two surfaces hand off to each other through the Edit with SG Builder action and the publish-back-to-record flow.

SG-Admin Appearance

Site-wide presentation defaults — themes, header / footer / mobile menu templates, custom fonts, custom codes, custom CSS — register in the admin Appearance. SG-Builder consumes those defaults and applies per-component overrides where the page needs them. Edits to site-wide presentation belong in the admin Appearance, not in SG-Builder.

Shared Concepts

The cross-platform rules and models SG-Builder depends on (site context, environment separation, ownership boundaries, structured composition).

Architecture and Reliability

The architectural framing for the platform's render path. SG-Builder produces layout that the platform renders server-side; the architectural posture behind that delivery is documented in Architecture and Reliability.

Constraints and boundaries

SG-Builder is a page composition surface. It should not be treated as the record administration layer or as the account-tier portfolio surface.

Use SG-Builder for:

• Layout composition for the active page or record.
• Responsive presentation tuning across the platform breakpoints.
• Per-page or per-component visual overrides on top of the site-wide defaults.
• Publishing the composed layout state when the work is ready.

Use SG-Admin for:

• Record administration (Pages, Blogs, Products, Forms, Custom Objects).
• Site-wide settings, theme registration, custom codes, custom fonts.
• Per-site users, permissions, and editorial workflows.

Use SG-Dashboard for:

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

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 component implementation, or protected service identifiers. Architectural depth lives in Architecture and Reliability and the per-component Reference pages, all written to the same public boundary.

Boundary at a glance

SG-Builder handles page-level visual composition. SG-Admin handles persistent site state. SG-Dashboard handles account portfolio. 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 composes a new blog post layout

The editor opens the admin → Blogs, creates a new post record, fills in the metadata, then clicks Edit with SG Builder. SG-Builder opens with the post's body canvas. The editor composes the layout from the block library, tunes responsive behavior at three breakpoints using the breakpoint switcher, then clicks publish. The post is now visible at the public URL.

Example 2 — Operator adjusts a product page layout for a launch

The operator opens the admin → STORE MANAGEMENT → Products, clicks into the product detail record, then clicks Edit with SG Builder to refine the product page layout. They adjust hero typography, swap a feature grid block for a comparison table, and tune the mobile breakpoint so the comparison table reads cleanly on narrow viewports. They publish, confirm on the live site, and close the editor.

Example 3 — Operator updates a page across two sites

An operator running two sites needs the same page layout change on both. They open the admin on the first site, click into the relevant Page record, click Edit with SG Builder, make the change, publish, close. They then switch to the second site via SG-Dashboard, open the equivalent Page record, click Edit with SG Builder, repeat. SG-Builder operates inside the active site context — there is no cross-site composition session.

Example 4 — Stakeholder asks "can SG-Builder edit two sites at once?"

The answer is no — SG-Builder operates inside the active site context only. Cross-site coordination happens at SG-Dashboard (portfolio surface); per-site composition happens at SG-Builder one site at a time. The boundary is intentional and is part of how the platform keeps site behavior separated even when an operator runs many sites.

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 (layout composition, responsive presentation, per-page presentation, publishing) rather than as a new top-level Builder category.

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

Where to find it

In SGEN Admin, navigate to any editable record — the admin → Pages, Blogs, Products, or Custom Objects — and click the Edit with SG Builder action on the record. SG-Builder opens embedded inside the admin at the page-tier editing environment for that record. There is no standalone SG-Builder URL; entry is always through a record in the admin.

Reading order across the section

Open the SG-Builder Overview (this page) first to anchor the model. Then descend into the per-component Reference pages in the order that matches the work — layout primitives first, then content components, then composite blocks. The component Reference pages can be read in any order; this Overview is the structural assumption every component page leans on.

Once the per-component Reference pages are anchored, the Guides for layout composition layer on top — task-shaped procedures with each Guide assuming the Reference is already understood. The pairing keeps the documentation legible: Reference for what the editor IS, Guides for what the operator DOES inside it.

Where SG-Builder appears on the live docs site

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

Related reading

• Platform Overview — system map across the three operating surfaces.
• SG-Admin Overview — the surface SG-Builder is embedded inside.
• SG-Dashboard Overview — the account-tier surface above SG-Admin.
• Shared Concepts — cross-platform models the editor depends on.
• Architecture and Reliability — architectural framing for the platform's render path.
• No-Plugin Architecture — the structural reasoning behind SG-Builder's first-party-only block library.
• Performance and Reliability — the delivery posture SG-Builder's output runs on.

Vocabulary cross-reference

• SG-Builder is the canonical surface name for the visual editor. Internal docs may shorten to "Builder" in body copy; surface naming stays "SG-Builder".
• Block refers to a top-level composable unit dragged onto the canvas (hero, section, grid, etc.).
• Component refers to a reusable visual unit inside a block (heading, button, image, list, etc.).
• Trait refers to a configurable property on a block or component (layout, decoration, content, behavior, responsive override).
• Breakpoint refers to one of the platform's standard responsive widths (1920 / 1199 / 991 / 767 / 575 / 480).
• Publish refers to the explicit operator action that promotes the unpublished editor state to the live page surface.