Integrations Model

How SGEN handles third-party connections — first-party connectors, configured at the platform tier, governed by the platform's release discipline.

SGEN's integrations model defines how the platform connects to external services — analytics warehouses, CRMs, marketing tools, payment providers, identity systems — without operators having to assemble a chain of vendor plugins, write glue code, or maintain a separate integration runtime per site. Connectors are first-party, configured at SG-Admin per site, audited like any other operator action, and released on the same platform cadence as the rest of SGEN.

This page sits next to Data and Tracking Model. The two pages overlap on downstream pipelines: data-and-tracking covers what gets captured and routed; this page covers how the routing target itself is configured and governed. Together they explain the path from "a Form was submitted on a page" to "the submission landed in the operator's CRM."

What is this for?

Read this page when you want the shared model behind integrations in SGEN. It defines what a connector is, how the configuration is scoped, what the platform takes responsibility for vs. what the operator configures, and how the release-and-audit posture pairs with the no-plugin architecture that the platform sits on.

The page is a Reference definition. It does not walk you through configuring a specific connector or enumerate the connector catalog at version v1; that detail lives in the per-area Reference (Integrations Overview) and in per-vendor Guides. It also does not enumerate per-customer custom connectors; that detail lives in the customer agreement.

Good use cases

• You are scoping a SGEN deployment and need to know how the platform handles integrations vs. a CMS where you would assemble a vendor plugin chain.
• You are working through an integration hand-off and need to understand which side configures what.
• You are reviewing the audit posture and need to see how integration changes pair with the rest of the platform's audit trail.
• You are designing a downstream pipeline (Form submissions to a CRM, analytics events to a warehouse) and need the shape of the configuration surface.
• You hit a "the connector is not firing" or "the integration disconnected" question and want the structural model behind health and failure handling.

What NOT to use this for

• Step-by-step configuration of a specific connector — open the per-vendor Guide.
• Per-customer custom-connector arrangements — internal-only or customer agreement.
• API-tier authentication mechanics for a downstream service — open Developer Reference if available.
• Per-release shipped behavior change — open What's New or Changelog.

How this connects to other features

• Environments and Site States — environment scope of integration configuration (per environment).
• Publishing Model — audit posture shared with integration configuration changes.
• Data and Tracking Model — capture surfaces that route through configured integrations.
• Roles and Access — who can configure connectors and read integration logs.
• Shared Concepts Index — sibling concept pages.
• SG-Admin Overview — per-site administrative surface where integrations are configured.
• Integrations Overview — per-area Reference with connector catalog and per-vendor framing.

Definition

A connector in SGEN is a first-party platform component that exposes a configurable connection between SGEN and an external service. Each connector ships with the platform, has a documented configuration surface, and runs on the same release cadence as the rest of SGEN.

The integrations model is the set of rules that govern how connectors are configured, scoped, audited, monitored, and released. Configuration is per-site (each site has its own connector instances and credentials). Audit is per-change (every connector configuration change is recorded). Release is platform-cadence (connectors are not separately versioned per site).

The defining property is first-party. SGEN does not sit on a marketplace of third-party plugins to provide integration. Instead, the platform ships the connector catalog directly, and the operator configures instances of those connectors at the per-site tier.

Purpose

The purpose of this page is to give operators a shared model of integrations so that connector configuration, integration audit, and downstream pipeline conversations all use the same vocabulary. Without that shared model, "integration" gets confused with "plugin", "configured" gets confused with "installed", and operators end up surprised when SGEN's release cadence applies to connectors uniformly rather than per-vendor.

Scope

This page covers the integrations model at the shared-concept level — the structure rather than the procedure.

The page covers:

• The definition of a connector and the integrations model.
• The configuration scope (per site, per environment).
• The platform-vs-operator responsibility split.
• The audit and release posture.
• The boundary against per-vendor configuration walkthroughs and custom-connector arrangements.

• Per-vendor connector procedures — open the per-vendor Guide.
• The current connector catalog at v1 — open the Integrations Overview.
• Per-customer custom connectors — customer agreement.
• API-tier authentication detail per vendor — open Developer Reference if available.

What the platform takes responsibility for

The platform owns several aspects of the integration runtime so that operators do not have to.

Connector code

The connector implementation lives in the platform codebase. Operators do not write or maintain the integration code. When a connector needs to update because the downstream vendor's API changed, the update lands as part of the platform release.

Credential storage

Credentials operators provide during configuration are stored under the platform's credential management. Operators do not have to design a per-site secret store, rotate credentials manually for connector code, or worry about exposure through a plugin codebase they did not author.

Health monitoring

Active connectors are monitored for connection health. When a connector fails to reach its downstream (credentials revoked, downstream service down, schema mismatch), the failure surfaces in the per-site administrative surface for the operator to address. The platform does not silently absorb integration failures.

Failure handling

When a downstream call fails, the platform handles the failure with discipline — retry policy, dead-letter behavior, surfacing — rather than dropping the captured event silently. Operators can read the failure log per connector to triage.

What the operator configures

The operator-side configuration is intentionally narrow.

Credentials and authentication

The operator provides the credentials the connector needs to reach the downstream service (an API key, an OAuth-grant flow, a service account). The credentials live in platform-managed storage after configuration; the operator does not have to maintain them in a separate secret manager.

Scope and routing

The operator selects which capture surfaces the connector should pull from (e.g. Form X submissions only, or Analytics events only) and any per-connector mapping the downstream service requires (field mapping, list mapping, segment mapping).

Per-site enablement

Each connector instance is per-site. Configuring a connector on Site A does not configure it on Site B; that is done as a separate operation per site, with its own credentials and scope.

Audit and release posture

Every connector configuration change is an audit event with operator identity, target connector, change scope, and timestamp. The audit record sits in the same audit surface that publishing-related events use, so an operator can answer "who changed the CRM mapping last week" without leaving the platform.

Connector versions follow the platform release cadence. When a connector's downstream API requires an adjustment, the change lands as part of a platform release rather than as a per-vendor plugin upgrade an operator has to apply. The release adopts the same controlled-change posture documented in the Architecture pages — predictable, governed, single-event.

Constraints and boundaries

Some properties of the integrations model are structural and worth naming explicitly so operators do not assume otherwise.

• Connectors are first-party. SGEN does not run on a third-party plugin marketplace. The connector catalog ships with the platform.
• Configuration is per-site. Each connector instance is per-site. Cross-site sharing of connector configuration is not the default; it would go through the customer agreement if required.
• Releases are platform-cadence. Operators do not upgrade connectors on a per-vendor schedule. Connector updates land as part of the platform release.
• Credentials are platform-managed. Operators provide credentials at configuration time. The platform stores them under its credential management; operators do not manage a separate secret store for connectors.
• Failure is surfaced, not absorbed. Connector failures appear in the admin so operators can triage; the platform does not silently drop captured events that fail to reach a downstream.

Examples

Example 1 — Connecting a CRM to receive Form submissions

A new CRM integration is needed for an account site. The Site Owner opens the admin Integrations, finds the CRM connector in the catalog (it ships with the platform), provides the API credentials, selects the Form whose submissions should route to the CRM, and maps the Form fields to the CRM fields. The connector is now active. Each subsequent Form submission routes both to the admin submission list and to the CRM. The audit trail records the configuration as a single event with operator identity.

Example 2 — Connector update that requires no operator action

The downstream CRM updates its API. The next platform release ships an updated connector that uses the new API. Operators do not have to upgrade a plugin, run a migration, or test compatibility per site — the update lands across all sites that have the connector configured, as part of the platform release. The audit trail of the per-site configuration is preserved across the connector update.

Example 3 — Triaging a connector failure

A connector starts failing because the downstream service revoked the credential. The failure surfaces in the admin's Integrations panel with the failure type and downstream response. The operator opens the connector configuration, rotates the credential, saves, and the connector reconnects. The failure event and the rotation event both live in the audit trail.

Example 4 — Disabling an integration cleanly

A campaign ends and the dedicated analytics warehouse it routed to is no longer needed. The Site Owner opens the connector and disables it. Capture events stop routing to that downstream; the connector configuration is preserved (so it can be re-enabled if the campaign returns) but no longer active. The audit trail records the disable event with operator identity and timestamp.

Example 5 — Multi-site account adding the same connector

An account has three sites. The same CRM is needed for all three. The operator configures the connector once per site — three separate configuration events, three sets of credentials (or three references to the same credential in a per-customer arrangement), three audit signatures. Each site has its own connector instance even when the downstream service is the same.

Example 6 — Auditing an integration change

A stakeholder asks "when did the CRM mapping change for this Form?" The operator opens the audit trail filtered to the connector and the date range. The audit signature shows operator identity, prior mapping, new mapping, and timestamp. The question is answered without leaving the platform.

Documentation guidance

This page is the shared definition of integrations. Use it as the vocabulary anchor when other Guides reference "connector", "integration", "configured connector", "connector update", or "integration audit". Per-vendor Guides describe how a specific connector is configured; this page describes the model that all connectors share.

For step-by-step configuration of a specific connector, open the per-vendor Guide. For the connector catalog at v1, open the Integrations Overview. For the audit posture this model shares with publishing, open Publishing Model. For how integration changes route through the per-site administrative surface, open the admin Overview.

Reading order

Read this page after Environments and Site States, Publishing Model, Roles and Access, and Data and Tracking Model. Those four set up the operating model and the data layer; this page extends to the integration layer that connects SGEN to external services.

Related reading

• Environments and Site States — environment scope of integration configuration.
• Publishing Model — audit posture shared with integration configuration.
• Data and Tracking Model — capture surfaces that route through configured integrations.
• Roles and Access — who can configure connectors.
• Shared Concepts Index — sibling concept pages.
• SG-Admin Overview — per-site surface where integrations are configured.
• Integrations Overview — per-area Reference with connector catalog.

Vocabulary cross-reference

• Connector — first-party platform component that exposes a configurable connection to an external service.
• Catalog — the platform's set of available connectors at the current release.
• Connector instance — a configured connector on a specific site with credentials and scope.
• Integration audit — the platform-managed record of connector configuration, credential rotation, enable, disable, and failure events.
• Health check — the platform-managed test that confirms a connector can reach its downstream.
• Failure log — the per-connector log of downstream call failures, with response codes and timestamps.
• Retry policy — the platform-defined behavior when a downstream call fails; determines how many attempts and what backoff applies before dead-letter.
• Dead letter — the holding state for capture events that could not be delivered after retries; surfaced for operator triage.
• Per-site instance — the per-site nature of connector configuration; each site has its own credentials and scope.
• Platform-cadence release — connector updates land on the platform's release schedule, not on per-vendor schedules.
• Operator-tier configuration — connector configuration is operator-tier (Site Owner) rather than database-tier or code-tier.
• Custom connector — an arrangement outside the standard catalog, negotiated through the customer agreement when a per-customer downstream needs platform-tier integration.
• Downstream service — the external system the connector targets (CRM, analytics warehouse, marketing tool, payment provider, identity system).
• OAuth-grant flow — the credential-handoff pattern where the operator authorizes SGEN to act on the downstream account; the resulting token lives in platform-managed storage.
• Service account — a credential type representing an automated identity (rather than a human operator) on the downstream service; common for system-to-system integrations.
• Field mapping — the per-connector configuration that pairs a SGEN capture-record field with the downstream service's equivalent field.
• List mapping — the per-connector configuration that routes captured records to the right destination collection on the downstream (a CRM list, an email-tool segment, an analytics view).
• Per-customer arrangement — a custom integration scope or credential model negotiated through the customer agreement; sits outside the standard connector configuration surface.
• Configuration surface — the per-connector form in the admin where credentials, scope, and mapping are entered; uniform across the catalog.
• Catalog entry — a single connector's representation in the catalog, showing whether it is configured for the current site.
• Connector update — an upgrade to a connector's implementation that lands as part of a platform release; transparent to operators because the downstream-facing behavior is preserved.
• Triage — operator action on a surfaced failure: rotate credentials, fix mapping, re-enable the connector, or escalate to platform support.
• Cross-connector audit — a single audit query that joins events from multiple connectors to answer "what changed across our integrations this week."
• Integration log — the per-connector record of recent activity (events sent, failures, retries) used for operator triage.
• Connector type — the classification of a connector by what type of downstream it targets (CRM, analytics, marketing, payment, identity, custom).
• Authoritative source — for any captured record, the platform is the source of record; the downstream service holds a routed copy, not the master.
• Reconnection — the operation of restoring a failed connector by rotating credentials or fixing scope; preserves prior configuration and audit history.
• Per-environment integration — the principle that a connector can be configured separately on staging vs live so test environments do not accidentally route to production downstreams.
• Operator-tier visibility — operators see connector configuration, status, audit, and failure logs without needing platform-team escalation for routine operations.
• Capture-to-downstream path — the end-to-end route from capture surface (Form, Analytics, Phone Tap, Event) → connector → downstream service; observable through the audit trail end-to-end.
• Schema mismatch — a class of failure where the downstream service's expected fields no longer match the connector's mapping; surfaced for operator triage.
• Catalog version — the connector catalog as it stands at a given platform release; recorded so audit reviewers can correlate connector behavior to the platform version of the moment.
• Connector documentation — the per-vendor Guide that walks operators through connecting a specific downstream; lives next to the per-area Integrations Reference.
• Per-customer custom connector — a connector built for a specific customer outside the standard catalog; arranged through the customer agreement with platform-tier support throughout its lifecycle.
• Default scope — the capture-surface and event-type defaults a connector applies if the operator does not narrow them at configuration time; documented in the per-vendor Guide.
• Triage queue — the admin surface where surfaced failures and dead-letter events are listed for operator action.