Reference → Publish Changes

Publish Changes

How the SG-Builder publish action works — explicit, atomic, validated, audited.

Publish Changes is the SG-Builder action that transitions the page from unpublished editor state to live page state. It is explicit (the operator clicks; nothing auto-publishes on save), atomic (either the publish succeeds and the page is live or it fails and nothing changes), validated (pre-publish checks run before transition), and audited (the publish event records to the audit log). This page is the Reference definition.

Publish Changes — Overview

Inline reference mock
+ Add New
FieldValue
ModulePublish Changes
Slugpublish-changes
SurfaceSg Builder / Overview
NotesReplace with captured screenshot when available

What is this for?

Read this page when you want the structural definition of the publish action — when to click it, what it transitions, and what the operator should expect.

Good use cases

  • You are scoping editorial workflows and need the publish-action model.
  • You are explaining to a stakeholder why publish is explicit and atomic.
  • You hit a "publish failed but the page state changed" question and want the model laid out.

What NOT to use this for

  • Step-by-step procedures — open the relevant Guide.
  • Per-component publish nuance — Component References.
  • Per-release shipped change — open What's New or Changelog.

How this connects to other features

Definition

Publish Changes is the explicit publish action inside the SG-Builder workspace. The action lives in the action bar at the top of the workspace. Clicking it triggers the publish workflow per the Publishing Workflow Reference: pre-publish validation, atomic transition, audit log entry.

The defining property is operator-initiated. The platform never auto-publishes on save. The operator's deliberate click is the gate.

Purpose

The purpose of this page is to define the publish action as a Reference layer rather than a procedural walkthrough. It explains the action's behavior, the validation that runs, and the audit trail that follows.

Scope

This page covers Publish Changes at the Reference level.

The page covers:

  • The action's location in the workspace.
  • The pre-publish validation.
  • The atomic transition behavior.
  • The audit trail.
  • The boundary against the broader Publishing Workflow Reference.

The page does not cover:

  • Step-by-step publish procedures — Guides.
  • Cross-product publish flow — Publishing Workflow Reference.
  • Per-release shipped change — What's New or Changelog.

Where the action lives

The publish button lives in the top action bar of the SG-Builder workspace, at the right edge. It is always visible during an editing session.

Save state indicator

A save indicator next to the publish button shows whether the editor has unsaved changes. The save state is independent of the publish state — saving keeps the change as a draft; publishing makes it live.

Publish Changes — Bar

Inline reference mock
+ Add New
FieldValue
ModulePublish Changes
Slugpublish-changes
SurfaceSg Builder / Bar
NotesReplace with captured screenshot when available

Pre-publish validation

When the operator clicks publish, the platform runs validation before transitioning state.

Required-field validation

Records (pages, posts, products) often have required fields administered through the admin module. Pre-publish validation confirms required fields are populated.

Structural constraints

The page must be structurally valid (no broken nesting, no required regions left empty).

Permission validation

The operator must have publish permission on the active site for the active record type.

A failing validation surfaces the issue inline; the publish does not proceed; nothing changes on the live site.

Publish Changes — Validation

Inline reference mock
+ Add New
FieldValue
ModulePublish Changes
Slugpublish-changes
SurfaceSg Builder / Validation
NotesReplace with captured screenshot when available

SG-Builder · Publish action sequence

Click → validate → transition → audit

SG-Buildermarketing.example · Homepage✓ Draft saved
1
Click publishOperator clicks the publish button in action bar
2
ValidateRequired fields, structure, permission checked
3
Atomic transitionEither succeeds fully or fails fully — no partial state
4
Audit log entryTimestamp, operator, page, before/after recorded

Atomic transition

The publish either succeeds entirely or fails entirely. There is no partial state where the page is half-published.

Success path

Validation passes; the platform transitions the page to published state; the live URL reflects the new state within the platform's render cadence; the audit log records the event.

Failure path

Validation fails or the transition itself errors; the operator sees an inline error; nothing changes on the live site; the audit log records the failed-publish attempt.

Audit trail

Every publish event records to the audit log:

  • Timestamp.
  • Operator identity.
  • Page / record identifier.
  • Before-state hint.
  • After-state.
  • Validation outcome.

The audit log is queryable per the broader audit-log surface.

Constraints and boundaries

Publish Changes is a Reference area for the SG-Builder publish action.

Use this Reference for:

  • Understanding when to publish.
  • Confirming the validation and audit behavior.

Do not use this Reference for:

  • Cross-product publish flow — Publishing Workflow Reference.
  • Per-step procedures — Guides.
  • Per-release shipped change — What's New or Changelog.

Public boundary

This page is intentionally public-safe.

Examples

Publish Changes — Examples

Inline reference mock
+ Add New
FieldValue
ModulePublish Changes
Slugpublish-changes
SurfaceSg Builder / Examples
NotesReplace with captured screenshot when available

Example 1 — Operator publishes a page edit

The operator finishes editing, clicks publish. Validation passes. The page transitions to published. Live URL updates within seconds.

Example 2 — Validation blocks an incomplete publish

The operator clicks publish; validation surfaces a missing required field. The publish does not proceed. The operator fills the field, clicks publish again, succeeds.

Example 3 — Operator audits a recent publish

A stakeholder asks who published a recent change. The operator opens the audit log, finds the publish event, sees timestamp + operator + before-state + after-state.

Documentation guidance

Publish Changes — Guidance

Inline reference mock
+ Add New
FieldValue
ModulePublish Changes
Slugpublish-changes
SurfaceSg Builder / Guidance
NotesReplace with captured screenshot when available

Use this page as the structural definition for the SG-Builder publish action. Cross-product detail lives in the Publishing Workflow Reference.

Where to find it

In SGEN Admin, open any editable record via Edit with SG Builder. The publish button appears in the top action bar of the SG-Builder workspace, at the right edge — always visible during an editing session. A save-state indicator next to the button shows whether unsaved changes are present before the publish action is clicked.

Reading order

Open this page when scoping the editor publish action. Pair with Publishing Workflow for the broader cross-product context.

Related reading

Publish Changes — Reading

Inline reference mock
+ Add New
FieldValue
ModulePublish Changes
Slugpublish-changes
SurfaceSg Builder / Reading
NotesReplace with captured screenshot when available

Vocabulary cross-reference

  • Publish action is the operator's click that initiates the publish.
  • Pre-publish validation is the check sequence that runs before transition.
  • Atomic transition is the property that publishing either fully succeeds or fully fails.
  • Audit entry is the record of the publish event in the audit log.

Maintenance discipline

When the publish action behavior changes across releases (new validation, new audit field, new transition rule), update this Reference and log the change in Changelog.

On this page