Workflows

Cross-product process flows that connect SG-Dashboard, SG-Builder, Automation, and Integrations.

Workflows in SGEN are the cross-product process flows that connect the wider platform. They describe how actions, approvals, updates, and operational transitions move between surfaces — SG-Dashboard, SG-Builder, automation-aware processes, and integration-dependent states. Each workflow defines an entry surface, the handoff points along the path, and the downstream effects that follow.

This page is the Reference definition of the Workflows surface. It establishes how workflows should be understood as a connective layer of the platform — the thing that explains why work that begins in one surface ends up visible elsewhere.

What is this for?

Read this page when you want the structural definition of Workflows — what the area covers, what counts as a workflow, where the boundary sits between Workflows and per-surface Reference, and how to read the per-workflow pages downstream.

The page is a Reference definition. It does not walk you through any specific workflow. Per-workflow detail (publishing workflow, content update workflow, site provisioning, form submission, lead-and-tracking, ticket-and-support, migration workflow, analytics-and-reporting) lives in the corresponding Workflows sub-pages.

Good use cases

• You are scoping a multi-team operation and need to understand where work passes from one surface to another.
• You are explaining to a stakeholder why an action in the admin produces an effect in SG-Dashboard or vice versa.
• You hit a "where did this state change come from?" question and want the platform's connective model laid out.
• You are designing internal SOPs and need the cross-product process model to anchor them.
• You are evaluating SGEN against a CMS-and-plugin alternative and need to see how the platform handles cross-product continuity.

What NOT to use this for

• Step-by-step procedures — open the relevant Guide.
• Per-surface deep detail — open the corresponding surface Reference (SG-Dashboard, SG-Builder).
• Per-workflow capability detail — open the corresponding Workflows sub-page.
• Integration-specific configuration — open the Integrations Reference.
• Automation behavior detail — open the Automation Reference.

How this connects to other features

• Platform Overview — the system map placing Workflows inside the Reference library.
• SG-Dashboard Overview — many workflows begin at the account tier.
• SG-Admin Overview — many workflows continue in site administration.
• SG-Builder Overview — workflows that involve presentation editing pass through SG-Builder.
• Automation Overview — workflows that include background or scheduled behavior.
• Integrations Overview — workflows that depend on connected third-party services.

Definition

Workflows in SGEN are the cross-product process flows that connect the wider platform. They describe how actions, approvals, updates, and operational transitions move between surfaces such as SG-Dashboard, SG-Builder, automation-aware processes, and integration-dependent states.

The defining property is span. A workflow involves more than one surface or system layer. Single-surface activity does not need a workflow page — the surface's own Reference covers it. Cross-surface activity, where the operator's work begins on one surface and continues on another, is what Workflows documents.

Purpose

The purpose of this page is to define workflows as a Reference layer for platform continuity. It establishes how the system should be understood when work begins in one surface, continues in another, and produces downstream effects elsewhere in the stack.

Scope

This page covers workflows at the Reference level. It is not a task guide and not a per-workflow tutorial — it defines how process continuity should be understood across the SGEN platform.

The page covers:

• Cross-product process flows rather than one isolated interface.
• How actions move between product surfaces and system-aware states.
• A stable Reference model for handoff, continuity, and operational interpretation.
• The boundary against per-surface Reference, per-Guide procedures, and Changelog release notes.

The page does not cover:

• Per-workflow capability detail — Workflows sub-pages.
• Per-surface deep detail — surface Reference pages.
• Step-by-step procedures — Guides.
• Per-release shipped change — What's New or Changelog.

Responsibilities

The Workflows area is responsible for making platform continuity explicit where one surface alone is not enough to explain what is happening.

Cross-surface continuity

Defines how activity moves from one product surface to another without breaking operational context. Operators who follow a workflow Reference understand where state changes happen even when those changes span multiple surfaces.

Handoff interpretation

Clarifies where responsibility shifts between dashboard control, site administration, visual editing, automation, or integrations. The handoff point is the moment a workflow stops being one surface's responsibility and becomes another's.

System process mapping

Provides a Reference model for workflows that involve multiple steps, multiple surfaces, or downstream system behavior. The map is not a procedure — it is the structural shape the procedure follows.

Key elements

Workflow Reference pages typically center on three structural elements: where the workflow begins, where it hands off, and what becomes visible afterward.

Entry surface

Defines where a workflow begins — a Dashboard action, an administrative change, or an integration-aware event. The entry surface anchors the workflow and is the first place an operator looks when troubleshooting a workflow that did not produce the expected result.

Handoff points

Defines where one surface stops owning the process and another surface or system layer takes over. Handoff points are the structural seams of the workflow; they are also the places where operators most often lose track of where the work currently lives.

Downstream effects

Defines what later states, dependent systems, or follow-on behaviors become relevant after the initial action. Downstream effects are how an operator confirms a workflow completed — they are the visible result the workflow exists to produce.

Workflow Reference pages currently in the section

The Workflows section in the Reference library covers the following per-workflow pages:

• Site provisioning
• Publishing workflow
• Content update workflow
• Form submission workflow
• Lead and tracking workflow
• Ticket and support workflow
• Migration workflow
• Analytics and reporting workflow
• Runtime context

Each per-workflow page applies the entry-surface / handoff-points / downstream-effects shape to the specific workflow it documents.

Operational role

Operationally, Workflows acts as the connective Reference layer of the platform. It explains how provisioning, content administration, builder activity, reporting behavior, integration-aware states, or recovery-sensitive operations fit together when the actual work spans more than one product area.

In daily operator use, Workflows is the surface a team opens when a question crosses surface boundaries — "where did the change go after I clicked publish?" or "what gets triggered when a form submits?" or "what happens between import and the imported records appearing in the admin?" Single-surface questions land on the relevant surface Reference; cross-surface questions land here.

Dependencies and related surfaces

Workflows should be read alongside the surfaces and system layers that participate in those flows.

SG-Dashboard

Many workflows begin at the account or portfolio level through Dashboard actions, setup routing, billing paths, or reporting entry points.

SG-Admin

Many workflows continue in the admin where records, settings, modules, and operational controls are administered.

SG-Builder

Builder becomes relevant when a workflow continues from administrative setup into presentation-level composition.

Automation

Some workflows include background behavior, scheduled activity, notifications, or system-driven handoff beyond the visible interface.

Integrations

External systems may initiate, enrich, or affect workflows when connected services are part of the operating path.

Migration and Import

Risk-sensitive workflows such as recovery, import validation, and rollback-aware activity have guarded flow definitions in the Migration and Import Reference.

Constraints and boundaries

Workflows is a Reference area for process structure and continuity. It should not be treated as a replacement for Guides, product surface definitions, or release communication.

Use Workflows for:

• Cross-surface process structure.
• Handoff definitions between product surfaces.
• Connective Reference between SG-Dashboard, SG-Builder, Automation, Integrations, and Migration and Import.

Use product Reference pages for:

• What each surface owns individually.

Use Guides for:

• Task-by-task operational procedures.

Use What's New or Changelog for:

• Shipped process changes or release-specific behavior.

Public boundary

This page is intentionally public-safe. It does not expose private infrastructure detail, internal credentials, exact integration credentials, or protected service identifiers.

Examples

Example 1 — Site provisioning crosses Dashboard, Admin, and Builder

The agency operator provisions a new site at SG-Dashboard → Site Manager → Add Site (entry surface). The new site lands under the account; the operator clicks into the site card and lands in the admin (first handoff). They configure site identity in the admin → Configuration, then open the homepage record and click Edit with SG Builder to compose the layout (second handoff). They publish; the rendered page becomes visible at the public site URL (downstream effect). Site provisioning is the cross-product workflow; the Workflows Reference documents the handoff sequence.

Example 2 — Form submission crosses public site, SG-Admin, Notifications, and Integrations

A visitor submits a form on the public site (entry surface — front end). The submission lands in the admin → My Forms (first handoff). A notification fires per the form's configured rules (second handoff — Automation territory). If the form is wired to a CRM or email-marketing integration, the submission also flows to that connected system (third handoff — Integrations territory). The operator confirms the submission appeared everywhere it was supposed to (downstream effect). The Workflows Reference for form submission documents the path.

Example 3 — Content update workflow crosses Admin, Builder, and live publish

The editor opens the admin → Pages, clicks an existing page record, then opens SG-Builder via Edit with SG Builder (first handoff). They make the edit, click Publish (second handoff — back to record state). The published version becomes visible on the public site (downstream effect). The operator confirms by visiting the public URL.

Documentation guidance

Use this page as a stable Reference definition. The shape on this page should remain consistent across releases — workflow additions land as new sub-pages under the Workflows section rather than as a new top-level Reference area. New workflow definitions should follow the same entry-surface / handoff-points / downstream-effects shape as the existing pages.

Procedural instruction belongs in Guides; per-release behavior change belongs in What's New or Changelog. Per-surface capability detail lives in the surface Reference pages, not in Workflows.

Reading order across the section

Open the Workflows Overview (this page) first to anchor the model. Then open the per-workflow Reference pages in the order that matches your work — Site provisioning for new-account scoping, Publishing workflow for editorial cycles, Content update workflow for ongoing editorial, Form submission for capture-side work, Lead-and-tracking for analytics, Ticket-and-support for service desks, Migration workflow for handoff operations, Analytics-and-reporting for portfolio measurement, Runtime context for cross-cutting concerns.

The per-workflow pages can be read in any order; this Overview is the structural assumption every per-workflow page leans on.

Related reading

• Platform Overview — system map.
• SG-Dashboard Overview — entry surface for many workflows.
• SG-Admin Overview — most workflow handoffs continue here.
• SG-Builder Overview — page composition handoff.
• Automation Overview — background behavior triggered by workflows.
• Integrations Overview — third-party services participating in workflows.
• Migration and Import Overview — risk-sensitive workflows.
• Shared Concepts — vocabulary the workflow definitions assume.

Vocabulary cross-reference

• Workflow is the canonical term for a cross-product process flow. Body copy may use "process" or "flow" interchangeably.
• Entry surface is the surface where a workflow begins.
• Handoff point is a moment in a workflow where ownership shifts from one surface or layer to another.
• Downstream effect is the visible result a workflow produces after its handoffs complete.
• Cross-product means the workflow involves more than one surface or system layer; single-surface activity is documented on the surface Reference, not here.

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.