Automation

System-driven behavior — triggered, scheduled, and integration-driven processes the platform owns.

Automation in SGEN refers to system-driven behavior that runs from triggers, schedules, or integration events. This area defines the control model — what kinds of automation exist, where their effects appear, and how operators should reason about them — rather than describing implementation code.

This page is the Reference definition of the Automation surface. It establishes how automation should be understood as a layer of platform behavior that runs outside the operator's direct interaction, and how the per-automation Reference pages (trigger model, scheduled processes, notification logic, backup and deploy automation, integration-driven automation, reporting automations) descend from this Overview.

What is this for?

Read this page when you want the structural definition of Automation — what counts as automation in SGEN, how the trigger / schedule / integration-event model is shaped, where the boundary sits between Automation and Workflows, and how the per-automation Reference pages relate to one another.

The page is a Reference definition. It does not walk you through how to configure any automation. Per-automation detail lives in the corresponding Automation sub-pages.

Good use cases

• You are scoping operator workflows and need to know what the platform automates by default.
• You are explaining to a stakeholder how SGEN handles background behavior without requiring per-customer configuration.
• You hit a "did the platform run something I didn't ask it to?" question and want the automation model laid out.
• You are designing internal SOPs and need to know which automation behaviors operators can rely on.
• You are evaluating SGEN against a CMS-and-plugin alternative and need to understand which automation is first-party rather than plugin-assembled.

What NOT to use this for

• Step-by-step procedures — open the relevant Guide.
• Per-automation capability detail — open the corresponding Automation sub-page.
• Cross-product process flow — open the Workflows Reference.
• Integration-specific configuration — open the Integrations Reference.
• Per-release shipped behavior change — open What's New or Changelog.

How this connects to other features

• Platform Overview — the system map placing Automation inside the Reference library.
• Workflows Overview — automation often participates in cross-product workflows; the Workflows Reference covers the cross-surface path, the Automation Reference covers the background behavior layer.
• Integrations Overview — integration-driven automation depends on connected services.
• Migration and Import Overview — backup and recovery-sensitive automation.
• Trigger Model — the per-automation Reference for how triggers are defined.
• Scheduled Processes — the per-automation Reference for time-based behavior.

Definition

Automation in SGEN is the layer of platform behavior that runs from triggers, schedules, or integration events rather than from direct operator interaction. The platform owns automation as a first-party concern — operators do not assemble automation from a stack of vendor plugins or external orchestration tools.

The defining property is that the operator does not have to be present for automation to run. A trigger fires; a schedule reaches its time; an integration event arrives. The platform handles the behavior consistently across every site, with no per-site assembly required.

Purpose

The purpose of this page is to define automation as a control model rather than as implementation code. It establishes what kinds of automation exist, where their effects become visible, and how operators should reason about them when scoping work or troubleshooting unexpected behavior.

Scope

This page covers automation at the Reference level — the surface as a control model rather than as a step-by-step configuration walkthrough.

The page covers:

• Automation behavior at the system level rather than a single screen.
• Event-driven, schedule-driven, and integration-driven behavior.
• Where operators should expect background processes to appear.
• The boundary against Workflows (cross-surface process), Integrations (third-party connections), and Migration and Import (recovery-sensitive operations).

The page does not cover:

• Per-automation configuration detail — Automation sub-pages.
• Per-area procedures — Guides.
• Cross-product process flow — Workflows Reference.
• Per-customer infrastructure detail — Infrastructure Overview or support escalation.

Responsibilities

The Automation area is responsible for making background and scheduled platform behavior legible to operators.

Trigger-driven behavior

Defines automation that fires on a defined event — a record being created, a form being submitted, a setting being changed, a state transition occurring. Trigger-driven automation responds to actions inside the platform.

Schedule-driven behavior

Defines automation that runs at a defined time — daily, weekly, monthly, or on a custom cadence. Schedule-driven automation does not depend on operator action; it runs because the schedule reached its time.

Integration-driven behavior

Defines automation that fires from a connected external service — an integration event arriving from a CRM, an analytics platform, a payment gateway, an email-marketing system. Integration-driven automation depends on the connection being healthy and configured.

Notification logic

Defines how operators are notified when automation runs — when a backup completes, when a scheduled report is ready, when an integration event surfaced an action item. Notification logic is the operator-facing seam of the automation layer.

Key elements

The Automation section covers the following per-automation Reference pages:

• Trigger Model — how triggers are defined across SGEN, what events count as triggers, and how triggers connect to downstream behavior.
• Scheduled Processes — how time-based automation is shaped, what cadences are available, and where scheduled behavior lands.
• Notification Logic — how operators receive notifications about automation outcomes, and how notification preferences are scoped.
• Backup and Deploy Automation — how backups, restores, and deploy-adjacent operations are automated and protected.
• Integration-driven Automation — how connected external services drive automation behavior inside SGEN.
• Reporting Automations — how reporting cadences and report-generation cycles are automated at the account or site tier.

Each per-automation page applies the trigger / schedule / integration-event model to the specific behavior it documents.

Operational role

Operationally, Automation is the layer of platform behavior the operator does not have to actively manage. Backups run on schedule. Reports generate on cadence. Notifications fire on event. Integration-event responses propagate without per-event manual handling.

In daily operator use, Automation is mostly invisible — the operator notices it when something doesn't fire (a backup didn't complete, a notification didn't arrive) or when a scheduled artifact lands (the daily report appears). The Reference exists to give operators the model for diagnosing both the missing-fire case and the unexpected-fire case.

Dependencies and related surfaces

Automation should be read alongside the surfaces and system layers that initiate, consume, or depend on automated behavior.

Workflows

Many cross-product workflows include automation steps. The Workflows Reference covers the cross-surface path; the Automation Reference covers the background behavior layer that participates in those workflows.

Integrations

Integration-driven automation depends on connected external services. Automation behavior surfaces inside SGEN; the connection itself is documented in the Integrations Reference.

Migration and Import

Backup, restore, and recovery-sensitive operations are automation territory but with extra discipline because they affect site state durably. The Migration and Import Reference covers the risk-aware framing for those automations.

SG-Admin

Many automation outcomes become visible inside the admin — backup history, scheduled report artifacts, notification logs. SG-Admin is where the operator confirms automation ran as expected.

SG-Dashboard

Account-tier automation outcomes (multi-site report rollups, account-wide backup status) surface in SG-Dashboard.

Constraints and boundaries

Automation is a Reference area for the control model behind background and scheduled behavior. It should not be treated as a substitute for Guides, per-surface Reference, or release communication.

Use Automation for:

• Reference definitions of background and scheduled behavior.
• The trigger / schedule / integration-event control model.
• Boundary definitions against Workflows, Integrations, and Migration and Import.

Use Workflows for:

• Cross-product process flow.

Use Integrations for:

• Connection-specific configuration of external services.

Use Guides for:

• Step-by-step procedures.

Use What's New or Changelog for:

• Per-release shipped behavior change.

Public boundary

This page is intentionally public-safe. It does not expose private infrastructure detail, exact scheduling internals, integration credentials, or protected service identifiers. Architectural depth lives in Architecture and Reliability and the per-automation Reference pages, all written to the same public boundary.

Examples

Example 1 — Operator confirms a daily backup ran

The operator opens the admin → CONFIGURATION → Tools → Backups (or the equivalent surface that exposes backup history) and confirms the daily backup ran. The Automation Reference defines the trigger / schedule model behind the backup; the admin surface is where the outcome is visible. If the backup did not run, the operator opens the Backup and Deploy Automation Reference page for diagnosis context, then escalates to support if the issue persists.

Example 2 — Editor expects a weekly report and it doesn't arrive

The editor expects a weekly site-traffic report on Mondays. The Monday passes without delivery. The editor opens the Reporting Automations Reference page, confirms the scheduled cadence configuration, then checks Notification Logic for whether the notification was suppressed. The Automation Reference gives the structural model that lets the editor reason about which layer of automation broke.

Example 3 — Stakeholder asks "what does SGEN automate without us configuring it?"

The stakeholder wants to know which automation is first-party-default rather than per-customer-configured. The platform lead opens this page, walks the four responsibilities (trigger-driven, schedule-driven, integration-driven, notification logic), and identifies which behaviors run by default (platform-managed backups, audit logs, deploy-adjacent automation) versus which require operator configuration (custom triggers, custom schedules, integration-specific responses). The Automation Reference is the structural source for the answer.

Documentation guidance

Use this page as a stable Reference definition. The shape on this page should remain consistent across releases — automation additions land as new sub-pages under the Automation section rather than as a new top-level Reference area.

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 Automation.

Where to find it

In SGEN Admin, navigate to the admin → Configuration → Tools to see automation outcomes such as backup history and scheduled job status. Automation behavior surfaces across modules — backup results appear under the Backups tab, notification outcomes under the Notification preferences panel, and account-tier automation artifacts in SG-Dashboard under Reports.

Reading order across the section

Open the Automation Overview (this page) first to anchor the model. Then open per-automation pages in the order that matches your work — Trigger Model and Scheduled Processes for the foundational shape, Notification Logic for the operator-facing seam, Backup and Deploy Automation for the high-stakes operations, Integration-driven Automation for connected-service behavior, Reporting Automations for the report-generation layer.

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

Related reading

• Platform Overview — system map.
• Workflows Overview — cross-product process flows that include automation.
• Integrations Overview — connected services that drive integration-event automation.
• Migration and Import Overview — risk-aware framing for backup, restore, and recovery automations.
• SG-Admin Overview — where many automation outcomes become visible.
• SG-Dashboard Overview — where account-tier automation outcomes surface.
• Shared Concepts — vocabulary the automation definitions assume.

Vocabulary cross-reference

• Automation is the canonical area name. Body copy may use "background behavior" or "scheduled behavior" where the prose flows.
• Trigger is an event that fires automation (record-created, form-submitted, state-transitioned).
• Schedule is a time-based cadence that fires automation (daily, weekly, monthly, custom).
• Integration event is an external-service event that fires automation (CRM update, payment received, email bounce).
• Notification is the operator-facing artifact that surfaces an automation outcome (toast, email, in-app indicator).

Maintenance discipline

When a new platform feature lands that includes background or scheduled behavior, do not add a new top-level Automation category by default. First check whether the behavior fits inside one of the existing four responsibilities (trigger-driven, schedule-driven, integration-driven, notification logic). Only add a new category when the feature genuinely defines a new automation primitive that does not fit the existing model.

The page stays valuable because it stays focused on the control model. Per-automation configuration detail belongs on the per-automation Reference pages; this Overview is the structural assumption those pages lean on.

Pairing with Workflows

For automation that participates in cross-product workflows, the pairing across the Reference library is intentional: open the Automation Overview for the background behavior model, then open the Workflows Reference for the cross-surface process flow that includes the automation. The two pages cover different layers of the same operational reality and read well together.

The same pairing pattern applies to Integrations (for integration-event automation), Migration and Import (for backup-and-recovery automation), and the per-surface Reference pages (for where automation outcomes become visible). Each pairing covers a different angle of the same automation behavior — the Automation Reference is the structural anchor that the others assume.