Notification Logic

How operators are notified of automation outcomes — channels, scope, suppression.

Notification Logic in SGEN is the layer that converts an automation outcome into an operator-facing artifact. Where Trigger Model and Scheduled Processes define what fires automation and when, Notification Logic defines how the operator finds out it ran. This page is the Reference definition of the notification primitive.

What is this for?

Read this page when you want the structural definition of SGEN's notification primitive — what channels are available, how notification scope works, and how suppression rules apply.

Good use cases

• You are scoping operator-facing alerting and need the notification model.
• You are explaining to a stakeholder how SGEN handles automation feedback.
• You hit a "why did I get five identical notifications?" question and want the model laid out.
• You are designing internal SOPs around notification triage.

What NOT to use this for

• Step-by-step notification configuration procedures — open the relevant Guide.
• Per-release shipped notification additions — open What's New or Changelog.
• Email-transport detail — open Email and SMTP.
• Per-trigger configuration — open Trigger Model.

How this connects to other features

• Automation Overview — parent Reference area.
• Trigger Model — what fires the automation that produces the notification.
• Scheduled Processes — what time-based jobs produce notifications.
• Email and SMTP — the transport layer for email notifications.

Definition

A notification in SGEN is the operator-facing artifact produced by an automation outcome. It carries a delivery channel, a recipient scope, a payload (what the operator needs to know), and an audit-log entry.

The defining property is operator-facing. Notifications are the seam between automation that runs in the background and the operator who needs to know it ran.

Purpose

The purpose of this page is to define the notification primitive as a Reference layer. It explains the channels, the scope model, the suppression rules, and how notifications pair with the broader automation layer.

Scope

This page covers notification logic at the Reference level.

The page covers:

• The delivery channels the platform exposes.
• The recipient scope model.
• The suppression rules that prevent notification noise.
• The audit log.
• The boundary against per-channel detail (Email and SMTP).

The page does not cover:

• Per-step notification configuration — Guides.
• Per-channel transport detail — channel-specific Reference (Email and SMTP).
• Per-release shipped notification additions — What's New or Changelog.

Delivery channels

Notifications can leave the platform through one or more channels.

In-app

The notification surfaces inside SGEN — Dashboard inbox, per-site notification surface inside the admin. The operator sees it the next time they open the platform.

Email

The notification leaves through the Email and SMTP transport, arriving at the recipient's inbox. Email is the most common channel for time-sensitive notifications.

Other channels

Future channel additions land here when they ship. Per-channel specifics live in their own Reference pages.

Recipient scope

Notifications can target one of several recipient scopes.

Operator

A specific operator inside the account. Personal notifications (a record the operator owns transitioning state) target the operator scope.

Role

Every operator with a defined role (admins, editors, support). Role-scoped notifications cover events that any operator in the role should know about.

Account

Every operator under the account. Account-tier events (billing, multi-site state) target the account scope.

Suppression rules

The platform applies suppression rules so notifications stay informative rather than overwhelming.

Deduplication

Identical notifications fired in rapid succession are deduplicated to one notification with a count indicator.

Digest rollup

High-volume notification streams (form submissions on a busy site, daily backup completions across many sites) can be rolled into a digest delivered on a defined cadence.

Per-event quotas

Some events have built-in quotas — only one "integration unhealthy" notification per integration per 24-hour window, for example — to prevent loop-style noise.

The audit log

Every notification fired is logged to the platform's audit-log layer. The log carries timestamp, event source, recipient, channel, and delivery state. Operators can review the log when reconstructing what notifications fired during an incident or migration window.

Constraints and boundaries

Notification Logic is a Reference area for the operator-facing seam of the automation layer. It is not a substitute for Trigger Model (event source), Scheduled Processes (time-based fire), or per-channel Reference (Email and SMTP).

Use this Reference for:

• Understanding notification channels, scope, and suppression.
• Diagnosing notification volume or missing-notification questions.

Do not use this Reference for:

• Per-trigger configuration — Trigger Model.
• Per-channel transport detail — channel-specific Reference.
• Step-by-step notification setup — Guides.

Public boundary

This page is intentionally public-safe. It does not expose notification-engine internals or protected operational identifiers.

Examples

Example 1 — Backup-completion notification fires daily

The daily backup completes; Notification Logic fires the in-app notification per the operator's preference. The same notification is suppressed from email per the operator's per-event channel routing. The operator sees the in-app notification next time they open SG-Dashboard.

Example 2 — Form-submission flood gets digested

A campaign produces many form submissions in a short window. The per-event digest rule rolls the submissions into a single notification covering the count and time window. The operator receives one notification instead of many.

Example 3 — Integration-unhealthy fires once

A connected integration goes unhealthy. The notification fires, gets logged, and the per-event quota suppresses repeat notifications for the next 24 hours. The operator sees one alert instead of repeated noise; the underlying state continues to surface in the connection panel.

Documentation guidance

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

Where to find it

In SGEN Admin, navigate to Automation → Notification Logic. Notification preferences and per-event channel routing appear inside the Configuration pillar under the labeled Notification preferences panel. The audit log for notification delivery is accessible from the same area under the Audit log tab.

Reading order

Open this page after Trigger Model and Scheduled Processes when reasoning about how automation outcomes reach operators. Pair with Email and SMTP for the email transport detail.

Related reading

• Automation Overview — parent Reference area.
• Trigger Model — event source layer.
• Scheduled Processes — time-based fire layer.
• Email and SMTP — email channel transport.

Vocabulary cross-reference

• Notification is the operator-facing artifact produced by an automation outcome.
• Channel is the delivery surface (in-app, email, others).
• Scope is the recipient set (operator, role, account).
• Suppression is the rule set that prevents notification noise.
• Audit log is the platform record of every notification fired.

Maintenance discipline

When notification logic changes across releases (new channel, new suppression rule, new scope option), update this Reference and log the change in Changelog. The page stays valuable because the four-element model (channel / scope / suppression / audit) stays small.