Workflows

Repeatable processes the platform ships as first-class workflows.

Workflows is the SGEN platform layer for repeatable, multi-step processes — moving a piece of work through its life cycle. Where Automations covers programmatic event-driven behavior, Workflows covers stateful, multi-step processes the platform recognizes as first-class. The result: operators get visible, auditable, configurable processes for the work that has stages.

What is this for?

Read this page to understand the Workflows layer of the SGEN platform — what workflows ship, what each is for, and how they sit alongside Automations and the modules they coordinate.

Good use cases

• You are scoping how the platform handles multi-step processes (publishing, lead routing, ticketing).
• You are deciding whether a process is a Workflow or an Automation.
• You are looking for the right workflow to model a specific business process.
• You hit a question like "How does SGEN handle the path from draft to published?"

What NOT to use this for

• Per-workflow setup steps — open the specific workflow's reference page.
• Custom workflows not on the shipped list — the Custom Codes module or Automations is the fallback.
• Operator orientation — open Getting Started with SGEN.

Before you start

You should have:

• A specific multi-step process in mind.
• Familiarity with the underlying SGEN modules the workflow coordinates (the Publishing workflow coordinates Pages and Posts, for example).

How this connects to other features

• Automations — event-driven programmatic behavior, often triggered by workflow transitions.
• SG-Modules — the modules that workflows coordinate.
• Integrations — external services workflows can route to.

Where to go

Each workflow has its own reference page. The Workflows section of the documentation lists them; this overview is the entry.

How workflows work

Steps — Use platform workflows

1. Recognize the workflow catalog

The shipped workflows include:

• Publishing Workflow — moves a content unit from draft through review to published, with documented states and approval points.
• Content Update Workflow — manages revisions on already-published content, including review and rollback.
• Lead and Tracking Workflow — moves a captured lead through attribution, scoring, and routing.
• Ticket and Support Workflow — routes support requests through triage, assignment, and resolution.
• Scheduled Processes — recurring tasks the platform runs on a schedule, with status visibility.
• Form Submission Workflow — flows a captured form submission through validation, storage, notification, and downstream integration.
• Migration Workflow — coordinates the multi-step migration of content into SGEN from external sources.

The catalog grows over releases. New workflows are added when a process across multiple operator workflows is common enough to deserve native first-class treatment.

2. Understand why workflows are platform-level

A workflow that lives in code is a developer dependency. A workflow that lives in a plugin is a vendor dependency. SGEN treats workflows as configurable platform features so the operator owns the process without owning the runtime.

Each workflow exposes its states, its rules, and its history through the admin surface. Audit logging records every transition. Operators can review what happened, when, and to which records — without standing up separate process-tracking infrastructure.

The trade-off: the workflows are opinionated. SGEN's Publishing workflow has specific states (draft, review, published, scheduled, trashed, restored); operators don't redefine those states arbitrarily. Configuration is around the workflow's behavior, not around its shape.

3. Identify which workflow matches a process

Most operator-side multi-step processes land on a specific workflow:

• Publishing a piece of content → Publishing Workflow.
• Editing already-published content with review → Content Update Workflow.
• Routing a captured lead through attribution → Lead and Tracking Workflow.
• Handling support requests through triage and assignment → Ticket and Support Workflow.
• Running recurring jobs (sitemap regen, backup, report generation) → Scheduled Processes.
• Handling a form submission end-to-end → Form Submission Workflow.
• Importing a site from another platform → Migration Workflow.

When a process doesn't fit a shipped workflow, the right move is usually to revisit the process shape — most operator-side processes have a workflow home. The Custom Codes module + Automations is the fallback.

4. Configure the workflow's behavior

Each workflow has its own configuration surface. Operators don't reshape the workflow's states; they configure how the workflow behaves at each state — who can transition between states, what triggers transitions, what happens automatically and what requires explicit action.

Configuration is per-site. Multi-site teams sometimes share configuration patterns through site templates; per-site overrides handle the cases where one site's process diverges.

5. Monitor workflow state and history

The platform's audit logging records every workflow transition. Operators can review the history per record — what state changes happened, when, who triggered them, what the outcome was.

The audit history is read-only. Operators can't edit historical transitions; the audit log preserves the actual sequence of events. Compliance teams can review the audit log for regulated processes.

What success looks like

• You know which workflow covers each multi-step process.
• You configure workflows deliberately rather than as defaults.
• You use the audit history when investigating what happened on a specific record.
• You don't reach for Custom Codes when a shipped workflow covers the case.

What to do if it does not work

The workflow isn't progressing as expected. Check the workflow's configuration. Most "not working" reactions resolve to "configured differently than expected." The reference clarifies.

A specific transition isn't allowed. Workflows enforce role-based transitions; the operator's role may not include the transition. Check role configuration and adjust if needed.

The audit history is missing entries. Audit logging is comprehensive across the workflow's transitions. Missing entries usually mean the action being looked for didn't trigger the workflow — check whether the action was a workflow transition or a separate operation.

A workflow is missing a state the process needs. Workflows are opinionated. If the missing state genuinely doesn't fit, the Custom Codes + Automations path is the fallback. Most "missing state" needs are addressed by configuring an existing state's behavior.

Best practices

• Use workflows for the processes they cover. Don't build parallel processes outside the workflow surface.
• Configure workflows once, deliberately. Half-configured workflows produce inconsistent behavior.
• Use the audit history routinely — it's the canonical source for "what happened."
• Watch release notes for workflow additions and behavior changes.

Common questions

How many workflows are there? Around half a dozen as of the most recent release shipped state. The count grows over releases.

Are workflows configurable per-site? Yes. Each site has its own workflow configuration. Multi-site teams sometimes replicate configuration; the platform supports this through site-level configuration tools.

Can I add a custom workflow? Custom workflows aren't first-class shipped features. The Custom Codes module and Automations layer cover custom-process needs. For very custom workflows, the platform team's roadmap is the right path — request the workflow as a platform feature if it's common across operators.

What's the relationship between Workflows and Automations? Workflows are stateful, multi-step, and operator-facing. Automations are event-driven, single-action, and often programmatic. They compose: a workflow transition can trigger an automation, which can in turn modify a workflow record.

Can I see all workflow transitions across the site? Yes. The Activity Feed surface aggregates transitions across all workflows for a holistic view of site activity.

Categories

The shipped workflows group into a few operational categories.

Content workflows — Publishing Workflow, Content Update Workflow. Concerned with the lifecycle of content records.

Lead and engagement workflows — Lead and Tracking Workflow, Form Submission Workflow. Concerned with visitor capture and follow-up.

Operational workflows — Ticket and Support Workflow, Scheduled Processes. Concerned with running the site's day-to-day operations.

Migration workflows — Migration Workflow. Concerned with bringing content into SGEN.

The categorization isn't strict. Some workflows span categories.

How workflows sit in the platform

Workflows sit alongside Automations at the platform layer. Where Automations is event-driven and reactive, Workflows is state-driven and proactive. They compose:

• Workflows model the path a record takes through its lifecycle.
• Automations model the actions that fire as records move along that path.

Operators usually don't have to choose between them; the right design uses both. A Publishing Workflow models the path from draft to published; an Automation fires the email-sending action when the workflow transitions to published.

Reading order

Read this overview once. Pair with Automations for the event-driven counterpart and SG-Modules for the underlying modules.

For each workflow you'll work with, follow the link from this page to the workflow's reference page.

Related reading

• Automations
• SG-Modules
• Integrations
• SG-Admin Activity Feed

Workflow states and transitions

A workflow at the platform layer is a state machine. Each workflow has a fixed set of states; transitions between states are governed by the workflow's rules.

State — the current position of a record in the workflow. A blog post can be in draft state, review state, published state, scheduled state, or trashed state. The state determines what's visible, what's allowed, and what happens next.

Transition — the move from one state to another. Transitions are triggered by operator actions (publishing, scheduling, trashing) or by automated rules (scheduled publish time arrives, review approval recorded).

Rule — the configuration that governs whether a transition is allowed. Rules cover role-based permissions (which operator roles can trigger which transitions), conditional logic (a transition can only fire if certain conditions are met), and timing (a transition can be deferred until a specific time).

The workflow's reference page describes its specific states and transitions. The shape is consistent across workflows — operators learn one workflow's pattern and recognize the same shape in others.

Multi-team workflows

For teams larger than a few operators, workflows often involve multiple roles — content authors, reviewers, publishers, support agents, marketing coordinators. The platform's role-and-permission system controls which transitions each role can trigger.

Common multi-role patterns:

Author + reviewer + publisher. Authors create and edit content, reviewers approve, publishers move to live. Each role has bounded permissions; the workflow enforces the boundaries.

Triage + assigned + resolved. Support workflows often have one role for initial triage, separate roles for assigned-handler and the resolution step. The workflow's transitions enforce the handoff.

Capture + qualify + route. Lead workflows often split capture (form submission, automatic) from qualification (an operator scoring or tagging) from routing (an operator assigning to a team).

The role configuration is per-site.

Teams establish their workflow-role mapping during platform onboarding.

The configuration usually stabilizes within the first month.

Once stable, the workflow-role mapping rarely needs further adjustment unless the team's role structure changes.

The platform's audit log captures the role of every operator who triggered each transition.

Teams have a clean record of who did what across the workflow's lifecycle.

The role-aware audit covers compliance, accountability, and operational review needs in one record.

Workflow performance characteristics

Workflows operate at the storage layer. State transitions write to the same tables that hold the underlying records; audit log entries write to dedicated audit tables. The platform optimizes both paths.

For routine operator workflows (a publishing transition per published page, a lead-routing transition per form submission), workflow operations add no measurable cost to the underlying record operations.

For high-volume scenarios (sites with thousands of records moving through the publishing workflow per day, scheduled processes running at peak times), the platform's monitoring tracks workflow performance alongside other platform performance. Operators rarely need to tune; the platform handles the routine cases.

Audit log retention

The audit log retains transitions according to the platform's data retention policy. Default retention is generous for most plans; operators in regulated industries can configure extended retention where their plan supports it.

Workflow versioning

Workflows version with the platform. The platform team coordinates breaking changes carefully; major shifts in workflow behavior are documented in release notes ahead of the release.

When a workflow gains a new state, the new state is documented in release notes. Existing records continue to operate under the prior states; new records pick up the new state where applicable.

When a workflow's transition rules change, existing records' history is preserved. The new rules apply to future transitions; the audit log shows the rules in effect at the time of each historical transition.

Migration to new workflow versions

For most workflow updates, no operator action is needed. The platform handles the migration to new workflow definitions automatically.

Operators occasionally need to review their per-workflow configuration after a major update — new configuration options may have defaults that don't match the operator's intended behavior. The release notes typically call these out.

Workflow audit logging

Every workflow transition is recorded in the platform's audit log. The log captures who triggered the transition, when, on which record, from which state to which state, and any conditions that affected the transition.

The audit log is the canonical source for "what happened" investigations. Compliance teams can review it for regulated processes; support teams can review it when investigating customer-facing issues; operators can review it when troubleshooting.

The log is read-only. Historical entries can't be edited or deleted; the platform preserves the actual sequence of events.

Querying the audit log

The audit log is queryable through the Activity Feed surface. Operators can filter by date range, by record, by transition type, by triggering operator. The query results show the relevant subset of the full audit history.

For programmatic access, the platform exposes audit history through standard data export tooling. Multi-site teams sometimes consolidate audit logs across sites for portfolio-level review.

About platform workflows

Platform workflows in this documentation refers to the shipped first-class workflows covered by this page. The phrase distinguishes platform workflows from custom processes operators build on top of the platform.

Platform workflows carry the platform's reliability, audit logging, and configurability guarantees. Custom processes built outside platform workflows carry operator-side responsibility.

Most operator-side processes get more value from platform workflows than from custom builds. The trade-off is opinion (the workflow has fixed states) for reliability (the platform handles state management).

About publishing workflow

The publishing workflow is the most commonly used SGEN workflow. It moves content records (Pages, Posts, Custom Object instances) from draft through optional review to published.

States: draft → optional review → published → scheduled (where applicable) → trashed → restored. Operators configure who can transition between states; the workflow enforces the configuration.

The publishing workflow integrates with revisions (every transition creates an audit entry), notifications (operators can be notified of transitions), and analytics (publish events flow into the analytics pipeline).

About lead workflow

The lead workflow handles captured visitor information from initial submission through routing. The workflow's states cover capture, attribution (where the visitor came from), scoring (where applicable), assignment (which operator owns the lead), and resolution (lead closed-won, closed-lost, in-progress).

The lead workflow integrates with the Forms module (form submissions create lead records), the Attributions module (visitor source data flows in), the ClickUp integration (lead records can be synced as tasks), and the Notifications module (lead alerts).

About process automation

Process automation in this documentation refers to the combination of workflows and automations working together. A process is automated when its multi-step path is modeled in a workflow and the actions at each step are handled by automations.

Most operator processes don't need full automation; partial automation is usually enough. A common pattern: workflow handles state, operators handle approvals, automations handle notifications. The mix is configurable per workflow.

Maintenance discipline

Update this page when:

• A new workflow ships in the catalog.
• An existing workflow is deprecated or replaced.
• The workflow architecture shifts in a way that affects how operators configure or monitor workflows.
• A new category emerges that warrants its own grouping.

Per-workflow changes (new states, new transition rules, new configuration options) belong in the specific workflow's reference page rather than here.

Scope

This Reference covers the platform-level shape of workflows: what the surface is responsible for, how it relates to neighboring surfaces, and the structural boundaries that hold across releases. Operator how-to and per-release change land on the linked operator-facing or changelog surfaces, not here.

Examples

• An operator opens this surface to confirm the structural shape before scoping a configuration change.
• A new team member reads end-to-end to build a mental model of the layer before touching any per-feature settings.
• An integrator references the relationship list to confirm which neighboring surface owns a specific behavior.

Fields