Integration-Driven Automation
How connected external services drive automation behavior inside SGEN.
Integration-driven Automation in SGEN is the variant of the trigger model where the event source is a connected external service rather than an internal platform event. Where the standard Trigger Model handles record events and form events, this layer handles webhook-style events arriving from CRMs, payment providers, email-marketing systems, and other connected services. This page is the Reference definition of the integration-event automation category.
What is this for?
Read this page when you want the structural definition of SGEN's integration-driven automation — what external events the platform exposes as triggers, how the dependency on the connected service shapes the automation, and where the outcomes surface.
Good use cases
- You are scoping automation that responds to external-service events (CRM updates, payment events, email bounces).
- You are explaining to a stakeholder how SGEN handles connected-service-driven background behavior.
- You hit a "the automation didn't fire on the external event" question and want the model laid out.
- You are designing internal SOPs around integration-aware automation.
What NOT to use this for
- Step-by-step integration-event configuration procedures — open the relevant Guide.
- Per-release shipped integration-event additions — open What's New or Changelog.
- The Trigger Model primitive itself — open Trigger Model.
- Per-integration setup — open the corresponding Integration Reference.
How this connects to other features
- Automation Overview — parent Reference area.
- Trigger Model — the broader trigger primitive that integration events plug into.
- Notification Logic — operator-facing seam for integration-event automation outcomes.
- Integrations Overview — the connected-service layer that produces the events.
Definition
Integration-driven Automation in SGEN is automation whose event source is a connected external service. The integration layer connects the external service; the trigger model picks up the external event when it arrives; the downstream behavior runs the same way it would for an internal event.
The defining property is external. The event originates outside SGEN — a CRM contact updates, a payment is captured, an email bounces — and SGEN responds by running the configured automation.
Purpose
The purpose of this page is to define integration-driven automation as a Reference layer. It explains what the external-event sources look like, how the dependency on the connected service shapes the automation, and where the outcomes pair with the broader notification and operations layers.
Scope
This page covers integration-driven automation at the Reference level.
The page covers:
- The kinds of external events the platform consumes.
- The dependency posture (what assumes what about the connected service).
- Where outcomes surface.
- The boundary against the broader Trigger Model and per-integration configuration.
- Per-step integration-event setup — Guides.
- Per-integration product detail — provider documentation.
- Per-release shipped event additions — What's New or Changelog.
External event sources
The platform consumes several classes of external events.
Connection-state events
Events from the integration layer itself — connection became unhealthy, connection restored, credentials expired. These events fire automation that updates internal state and notifies operators.
Service-data events
Events that carry payload from the connected service — CRM record updated, payment authorized, email-marketing send completed. These events fire automation that takes action on the SGEN side based on the external payload.
Service-action events
Events that signal the external service took an action SGEN should respond to — a webhook callback after a long-running external job, a delivery confirmation, a status change.
Site · Automation · Integration-driven
External-event flow
External
Provider event
payment.captured
Trigger fires
SGEN trigger
condition: amount > 0
Downstream
Action
update Order status, notify operator
14:32:08 · trigger fired · condition pass
14:32:09 · order status: paid · notification queued
14:32:11 · email delivered to operator
Dependency posture
Integration-driven automation depends on the connected service being healthy and the integration credentials staying valid.
Healthy connection
External events arrive within the provider's normal latency. Triggers fire as expected; downstream behavior runs cleanly.
Unhealthy connection
External events stop arriving. Automation that depends on the events stops firing. The connection panel surfaces the unhealthy state; Notification Logic delivers a high-priority alert.
Where outcomes surface
Integration-event automation outcomes surface in the same places as other automation outcomes — the relevant SG-Admin module, the Notification surface, the audit log. The shape is consistent regardless of whether the trigger source was internal or external.
Constraints and boundaries
Integration-driven Automation is a Reference area for the external-event variant of the trigger model. It is not a substitute for the Trigger Model primitive or for per-integration documentation.
Use this Reference for:
- Understanding the external-event automation shape.
- Reasoning about dependency on the connected service.
- Diagnosing missing-fire questions when external events fail to trigger automation.
- The Trigger Model primitive — Trigger Model Reference.
- Per-integration configuration — Integrations Reference.
- Step-by-step setup — Guides.
Public boundary
This page is intentionally public-safe. It does not expose webhook internals, payload schemas, or protected operational identifiers.
Examples
Example 1 — Payment captured fires order-update automation
The payment provider captures a transaction. The webhook event arrives at SGEN. The integration-event trigger fires; the condition passes; the downstream behavior updates the order status in the admin → Orders and queues a notification to the operator.
Example 2 — CRM record update fires content-sync automation
The CRM updates a customer record. The webhook event arrives at SGEN. The integration-event trigger fires; the downstream behavior updates the corresponding Custom Object record on the SGEN side. Both surfaces stay in sync without manual intervention.
Example 3 — Connection goes unhealthy and automation pauses
The connected service becomes unreachable. External events stop arriving. The connection panel surfaces the unhealthy state; Notification Logic delivers a high-priority alert. Automation that depends on those events pauses cleanly until the connection is restored.
Documentation guidance
Use this page as the structural definition for integration-driven automation. Procedural detail belongs in Guides; per-release behavior change belongs in What's New or Changelog. Cross-reference Trigger Model for the broader primitive and Integrations for the connection layer.Reading order
Open this page after Trigger Model and Integrations Overview. The two together provide the framework this Reference applies to external events.
Related reading
- Automation Overview — parent Reference area.
- Trigger Model — broader trigger primitive.
- Notification Logic — operator-facing notification layer.
- Integrations Overview — connected service layer.
Vocabulary cross-reference
- Integration event is an event that originates from a connected external service.
- Webhook is the common transport for external-event delivery.
- External-event trigger is a trigger whose event source is an integration event.
- Connection-state event is an event from the integration layer about the connection itself (healthy / unhealthy).
- Service-data event is an event carrying payload from the connected service.
Maintenance discipline
When integration-driven automation behavior changes across releases (new external-event source, new dependency posture, new payload shape), update this Reference and log the change in Changelog. The page stays valuable because the external-event-trigger model stays small and consistent with the broader Trigger Model.