Integrations Model

In short. SGEN connects to external services — CRMs, analytics warehouses, marketing tools, payment providers — through first-party connectors that ship with the platform. You configure a connector with credentials and scope; the platform handles storage, health checks, failure surfacing, and updates on the same release cadence as everything else. No plugin installs, no per-vendor upgrade chains, no glue code.

On this page: What a connector is · Platform vs. operator responsibilities · Audit and release posture · Constraints · Examples · Vocabulary

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 — connector catalog and per-vendor guides.

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 configuration change is recorded with operator identity and timestamp.
• Release is platform-cadence — connectors are not separately versioned per site.

The defining property is first-party. SGEN does not rely on a marketplace of third-party plugins to provide integration. The platform ships the connector catalog directly; operators configure instances of those connectors at the per-site tier.

What the platform takes responsibility for

The platform owns the integration runtime so operators do not have to.

Connector code

The connector implementation lives in the platform codebase. When a downstream vendor's API changes, the update lands as part of a platform release — not as a per-vendor plugin upgrade an operator has to apply.

Credential storage

Credentials entered at configuration time are stored under the platform's credential management. Operators do not design a per-site secret store 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, service down, schema mismatch — the failure surfaces in the per-site admin for the operator to address. The platform does not silently absorb integration failures.

Failure handling

When a downstream call fails, the platform retries, dead-letters, and surfaces the failure in a per-connector log. Operators can read the failure log to triage; events are not silently dropped.

What the operator configures

Operator-side configuration is intentionally narrow.

Credentials and authentication

The operator provides the credentials the connector needs to reach the downstream service. Those credentials live in platform-managed storage after configuration.

Scope and routing

The operator selects which capture surfaces the connector should pull from (for example, Form 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.

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.

Constraints and boundaries

Some properties of the integrations model are structural.

• 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.
• Releases are platform-cadence. Operators do not upgrade connectors on a per-vendor schedule.
• Credentials are platform-managed. The platform stores credentials under its own credential management; operators do not maintain a separate secret store for connectors.
• Failure is surfaced, not absorbed. Connector failures appear in the admin for operator triage; the platform does not silently drop captured events that fail to reach a downstream.

Examples

Connecting a CRM to receive Form submissions

Open the admin Integrations, find the CRM connector in the catalog, provide credentials, select the Form whose submissions should route to the CRM, and map the Form fields to the CRM fields. The connector is now active — each subsequent 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.

Handling a connector update

The downstream CRM updates its API. The next platform release ships an updated connector. Operators do not upgrade a plugin or test compatibility per site — the update lands across all sites that have the connector configured. The per-site audit history is preserved across the connector update.

Triaging a connector failure

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

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, surfaced for operator triage.
• Dead letter — the holding state for captured events that could not be delivered after retries.
• Field mapping — the per-connector configuration that pairs a SGEN capture-record field with the downstream service's equivalent field.
• Per-environment integration — a connector can be configured separately on staging vs live so test environments do not accidentally route to production downstreams.
• Authoritative source — for any captured record, the platform is the source of record; the downstream service holds a routed copy, not the master.

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.