Trigger Model
How triggers are defined across SGEN — event sources, conditions, downstream behavior.
The trigger model in SGEN defines how event-driven automation is shaped — what events count as triggers, what conditions can apply, and how triggered behavior connects to downstream effects across the platform. This page is the Reference definition of the trigger primitive that the Automation section uses.
What is this for?
Read this page when you want the structural definition of SGEN's trigger primitive — what events the platform exposes as triggers, how trigger conditions are shaped, and how the trigger model differs from the schedule model.
Good use cases
- You are scoping event-driven automation for a site and need the trigger inventory.
- You are explaining to a stakeholder how SGEN handles event-driven background behavior.
- You hit a "what fires this notification?" question and want the model laid out.
- You are designing internal SOPs around automation handoff.
What NOT to use this for
- Step-by-step trigger configuration procedures — open the relevant Guide.
- Per-release shipped trigger additions — open What's New or Changelog.
- Schedule-driven automation — open Scheduled Processes.
- Integration-event automation — open Integration-driven Automation.
How this connects to other features
- Automation Overview — parent Reference area.
- Scheduled Processes — sibling automation primitive (time-based vs event-based).
- Notification Logic — how trigger outcomes become operator-facing notifications.
- Integration-driven Automation — the integration-event variant of the trigger model.
Definition
A trigger in SGEN is a defined event that fires automation. The trigger has three structural parts: the event source (what changed in the platform), the condition (any filter that constrains when the event qualifies), and the downstream behavior (what the platform does in response).
The defining property is reactive. Triggers respond to events that happen inside the platform. Schedule-driven automation is the time-based counterpart; integration-driven automation is the external-event variant.
Purpose
The purpose of this page is to define the trigger primitive as a Reference layer. It explains the structural parts, the event sources the platform exposes, the condition model, and the downstream-behavior layer.
Scope
This page covers the trigger primitive at the Reference level.
The page covers:
- The structural parts of a trigger (event source, condition, downstream behavior).
- The event sources the platform exposes as triggers.
- The boundary against schedule-driven automation and integration-event automation.
- Per-trigger configuration procedures — Guides.
- Per-release shipped trigger additions — What's New or Changelog.
- Custom integration triggers — Integration-driven Automation Reference.
Event sources
SGEN exposes events as triggers across the major surfaces.
Record events
A record being created, updated, deleted, or having a state change (draft → published, published → archived). Record events fire from the admin module actions.
Form events
A visitor submitting a form. The form-submission event is the most common trigger source for capture-side automation.
State events
A state-level change inside a module (a setting toggling, a configuration changing, a workflow advancing).
System events
Backup completion, deploy completion, scheduled-process completion. System events bridge the trigger model and the schedule model — a scheduled process completing fires a trigger that downstream automation can respond to.
Site · Automation · Trigger
Form submission → notification
Event source
form.submitted
Fires when a visitor submits any configured form on this site.
Condition
form.id == "contact" AND form.field.email exists
Constrains the trigger to the contact form only, with a populated email field.
Downstream behavior
send_notification(template="contact-confirmation")
EmailNotification log Confirmation email to submitter; entry recorded in notification log.
The condition layer
Triggers can carry conditions that constrain when the trigger fires. The condition layer keeps the trigger model precise — a trigger without conditions fires on every matching event; a trigger with conditions fires only when the conditions pass.
Condition shape
Conditions are expressed as constraints on the event payload — record type, field values, source surface, time-of-day windows. The condition is evaluated when the event arrives; if the condition fails, the trigger does not fire downstream behavior.
The downstream-behavior layer
When a trigger fires, the downstream behavior runs. The behavior is what the platform does in response — sending a notification, creating a derived record, queueing a background job, propagating state to a connected integration.
Behavior categories
Notification (Notification Logic Reference covers this), record action (create / update inside the admin modules), background job (queued via the scheduled-processes infrastructure), integration push (out to a connected service via Integration-driven Automation).
Constraints and boundaries
Trigger Model is a Reference area for the event-driven automation primitive. It is not a substitute for Scheduled Processes (time-based) or Integration-driven Automation (external-event-based).
Use this Reference for:
- Understanding the structural shape of an SGEN trigger.
- Confirming what event sources are available.
- Reasoning about downstream behavior when a trigger fires.
- Time-based automation — Scheduled Processes.
- Integration-event automation — Integration-driven Automation.
- Step-by-step trigger configuration — Guides.
Public boundary
This page is intentionally public-safe. It does not expose trigger-engine internals, exact event-payload schemas, or protected operational identifiers.
Examples
Example 1 — Form submission triggers a confirmation email
The form-submission trigger fires when a visitor submits the contact form. The condition layer constrains the trigger to that form. The downstream behavior sends a confirmation email through the Email and SMTP transport.
Example 2 — Record published triggers a notification to the editor
The record-state-change trigger fires when a page transitions draft → published. The condition layer constrains the trigger to records the editor authored. The downstream behavior sends a notification to the editor's notification surface.
Example 3 — Backup completion triggers downstream cleanup
The system-event trigger fires when a backup completes. The condition layer constrains the trigger to scheduled backups (not on-demand). The downstream behavior runs a cleanup of stale references in the notification log.
Documentation guidance
Use this page as the structural definition for the trigger primitive. Procedural detail belongs in Guides; per-release behavior change belongs in What's New or Changelog.Reading order
Open this page after the Automation Overview when scoping any event-driven automation. Pair with Notification Logic for the operator-facing seam, Scheduled Processes for the time-based counterpart, Integration-driven Automation for the external-event variant.
Related reading
- Automation Overview — parent Reference area.
- Scheduled Processes — sibling primitive.
- Notification Logic — operator-facing notification layer.
- Integration-driven Automation — external-event variant.
Vocabulary cross-reference
- Trigger is a defined event that fires automation.
- Event source is what changed in the platform that produced the event.
- Condition is a constraint that determines whether a matching event fires the trigger.
- Downstream behavior is what the platform does when the trigger fires.
- Reactive is the property that distinguishes triggers from schedules (time-based).
Maintenance discipline
When the trigger model changes across releases (new event source, new condition shape, new downstream behavior category), update this Reference and log the change in Changelog. The page stays valuable because the three-part shape (event source / condition / downstream behavior) stays small.