Content Update Workflow

How an existing record is updated and re-published — the everyday editorial cycle.

The Content Update Workflow is the cross-product process for updating existing content. It begins inside the admin where the operator opens the record, hands off to SG-Builder for visual edits when needed, returns to the publish action, and ends with the updated content live at the public URL. This page is the Reference definition.

What is this for?

Read this page when you want the structural definition of the everyday content-update cycle — the entry surface, the edit-handoff, the re-publish action, and the audit trail.

Good use cases

• You are scoping editorial workflows for an editorial team.
• You are explaining to a stakeholder how SGEN handles ongoing content edits.
• You hit a "where do edits happen?" 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.
• Publishing Workflow — the publish-action layer the update workflow ends with.
• Site Provisioning — sibling that sets up the surface this update operates on.
• SG-Admin Overview — entry surface.
• SG-Builder Overview — visual edit handoff.

Definition

The Content Update Workflow is the cross-product process that updates an existing record and re-publishes the changed state. It assumes the record exists; it covers the editorial cycle from open through edit through re-publish.

The defining property is iterative. The same record may go through this workflow many times across its lifetime; the cycle is short, focused, and repeatable.

Purpose

The purpose of this page is to define the content-update cycle as a Reference layer. It explains the cycle's shape and how it pairs with the Publishing Workflow at the end.

Scope

This page covers the workflow at the Reference level.

The page covers:

• The entry surface (SG-Admin record).
• The edit handoff (in-place edit OR open in SG-Builder).
• The re-publish action.
• The downstream effect (live site updated).

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

Entry surface

SG-Admin record list

The operator opens the relevant SG-Admin module (Pages, Blogs, Products, etc.), scans the record list, and clicks into the record needing an update.

Edit handoff

In-place edit

For records edited as structured fields (a blog post's title and body, a product's price and inventory), the operator edits in place inside the admin and saves draft.

Open in SG-Builder

For records edited as visual page composition, the operator clicks Edit with SG Builder. SG-Builder loads in the active site context. The operator edits visually and returns to publish.

Re-publish action

The re-publish action follows the Publishing Workflow shape — explicit, atomic, validated, audited. The updated content goes live at the public URL after the publish succeeds.

Downstream effects

Live site updated

The public surface reflects the updated content within the platform's render cadence (typically near-immediate for SSR-rendered pages).

Audit log entry

The publish event records to the audit log per the Publishing Workflow audit pattern.

Notification fire

If notifications are configured for the relevant event (e.g., editor publish notifications go to a section lead), Notification Logic delivers per preferences.

Constraints and boundaries

This Reference covers the everyday update cycle. Per-surface and per-step detail lives in surface References and Guides.

Use this Reference for:

• Understanding the everyday content-update cycle.
• Reasoning about handoffs between the admin and SG-Builder during updates.

• Step-by-step procedures — Guides.
• Per-record-type 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 updates a blog post

The editor opens the admin → Blogs, clicks the post, edits the title in place, opens the body in SG-Builder for visual layout adjustment, returns and clicks publish. The updated post is live.

Example 2 — Operator updates a product price

The operator opens the admin → STORE MANAGEMENT → Products, clicks the product, edits the price field in place, clicks publish. SG-Builder is not involved (the price is a structured field).

Example 3 — Editor updates a complex page hero

The editor opens the admin → Pages, opens the homepage, clicks Edit with SG Builder. They adjust hero content, swap a section, tune responsive behavior at the mobile breakpoint, and publish from inside SG-Builder.

Documentation guidance

Use this page as the structural definition for the everyday content update cycle. 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 update-cycle questions.

Related reading

• Workflows Overview — parent Reference area.
• Publishing Workflow — the publish-action layer.
• Site Provisioning — sibling that establishes the surface.
• SG-Admin Overview — entry surface.
• SG-Builder Overview — visual edit handoff.
• Migration Workflow — sibling for initial site setup.
• Form Submission Workflow — sibling for form-driven content.

Vocabulary cross-reference

• Update cycle is one open-edit-publish iteration of the workflow.
• In-place edit is editing structured fields directly in the admin.
• Visual edit is editing visual layout via SG-Builder.
• Re-publish is the publish action on already-existing content.

Maintenance discipline

When the content update cycle changes across releases (new edit surface, new handoff path, new audit field), update this Reference and log the change in Changelog.

Related reading