Publishing Workflow

How content moves from draft to live — explicit publish, staging-to-live promotion, audit trail.

The Publishing Workflow is the cross-product process that takes content from draft state to live, visible state. It begins inside the admin or SG-Builder where the operator authors or edits the content, transitions through the explicit publish action, and ends with the live site reflecting the change. This page is the Reference definition.

What is this for?

Read this page when you want the structural definition of the publish path — entry surface, the publish action, what becomes visible, and the audit trail.

Good use cases

• You are scoping editorial workflows and need the publish-path model.
• You are explaining to a stakeholder why publish is explicit (not auto-publish on save).
• You hit a "is this change live yet?" question and want the model laid out.

What NOT to use this for

• Step-by-step procedures — open the relevant Guide.
• Per-release shipped change — open What's New or Changelog.
• Per-component capability detail — open the corresponding surface Reference.

How this connects to other features

• Workflows Overview — parent Reference area.
• Content Update Workflow — sibling workflow for edit cycles.
• Site Provisioning — sibling workflow that sets up the surface this publish operates on.
• SG-Builder Overview — page-level publish surface.
• SG-Admin Overview — record-level state transitions.

Definition

The Publishing Workflow is the cross-product process that converts authored or edited content into live, visitor-facing content. The workflow has an entry surface (SG-Admin record state OR SG-Builder editor state), an explicit publish action, and downstream effects (rendered content at the public URL, audit log entry, notification fire where configured).

The defining property is explicit. Publishing is never an automatic side effect of saving; it requires the operator's deliberate publish action. The discipline keeps the live site predictable.

Purpose

The purpose of this page is to define publishing as a Reference layer. It explains the publish action, the staging-to-live promotion variant, and the audit trail that follows.

Scope

This page covers the workflow at the Reference level.

The page covers:

• The entry surfaces (SG-Admin record, SG-Builder editor).
• The explicit publish action.
• The staging-to-live promotion variant.
• The audit trail.

• Step-by-step procedures — Guides.
• Per-record-type publish nuance — per-module Reference.
• Per-release shipped change — What's New or Changelog.

Entry surfaces

SG-Admin record state

For records administered without page-level composition (some module types), the publish action lives on the record's SG-Admin surface. The record transitions draft → published at this surface.

SG-Builder editor state

For records with page-level visual composition (Pages, Posts, Products, Custom Objects with builder enabled), the publish action lives at the SG-Builder editor's publish button. The page transitions unpublished editor state → published live state.

The publish action

The publish action is explicit and atomic. The operator clicks; the platform validates the publishable state; the record or page transitions; the live site updates.

Pre-publish validation

The platform checks that required fields are populated, structural constraints are met, and the operator has permission to publish.

Atomic transition

Publishing is atomic — either it succeeds and the live site updates, or it fails and nothing changes. Partial-publish states do not exist.

Confirmation

The operator sees a confirmation message; the next surface load reflects the new published state.

Staging-to-live promotion variant

For sites with staging environments enabled, publish goes to staging first; promotion to live is a separate explicit action.

Why two-step

The staging surface lets the team preview the live state before visitors see it. Promotion is the gate.

Promotion action

After confirming staging looks correct, the operator promotes staging to live via the promotion action. The promotion is the same atomic shape as a direct publish.

Audit trail

Every publish event is logged. The audit log records timestamp, operator, record / page identifier, before-state hint, and after-state.

Constraints and boundaries

This Reference covers the cross-product publish workflow. Per-surface detail lives in the surface References.

Use this Reference for:

• Understanding the publish-path model.
• Confirming why publish is explicit and atomic.
• Reasoning about staging-to-live promotion.

• Per-step publish UX — surface References.
• Per-record-type publish nuance — per-module Reference.
• Per-release shipped change — What's New or Changelog.

Public boundary

This page is intentionally public-safe.

Examples

Example 1 — Editor publishes a new blog post

The editor authors the post in the admin → Blogs, opens it in SG-Builder, composes layout, clicks publish in SG-Builder. The post is live at the public URL. The audit log records the event.

Example 2 — Operator promotes staging to live

The operator publishes a redesign to staging. The team reviews on the staging URL. The operator clicks promote-to-live; the live site updates. Two-step discipline kept the operator in control of the visibility moment.

Example 3 — Pre-publish validation blocks an incomplete publish

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

Documentation guidance

Use this page as the structural definition for the publish workflow. Procedural detail belongs in Guides; per-release behavior change belongs in What's New or Changelog.

Reading order

Open this page when scoping editorial workflows or troubleshooting publish-related questions.

Related reading

• Workflows Overview — parent Reference area.
• Content Update Workflow — sibling for edit cycles.
• Site Provisioning — sibling for new-site setup.
• SG-Builder Overview — page-level publish surface.
• SG-Admin Overview — record-level state transitions.
• Migration Workflow — sibling for first-time migration.
• Form Submission Workflow — sibling for form-driven publish flows.

Vocabulary cross-reference

• Draft is the unpublished editor or record state.
• Published is the live, visitor-facing state.
• Publish action is the explicit operator action that transitions draft → published.
• Staging-to-live promotion is the two-step variant where publish goes to staging then promotes to live.
• Atomic transition is the property that publishing either fully succeeds or fully fails — no partial states.

Maintenance discipline

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

Related reading