Connected Systems

In the current ODA implementation, connected systems used in Data Studio authoring are secret-backed account integrations surfaced as selectable system nodes on the project canvas. When you click Add a system, the picker is populated from account data secrets that are enabled for use, and each system entry includes its secret type context.

From a lineage perspective, selecting a system creates a system_node in the project graph, and that node stores the selected secret ID as its kind_id. Source nodes are then added under that system and inherit lineage to it, so downstream ingestion and transformation steps can resolve the correct connection context consistently.

How Connected Systems Are Resolved

When you start source setup from a selected system node, the source panel uses that system's secret ID and resolves connector behavior by secret type. The source setup flow is handler-driven, which means the UI and validation logic are selected dynamically based on the registered source-type module for that secret type.

If a system's secret type is not supported by the source handler registry, the UI shows an explicit unsupported-type message and blocks source configuration for that path until a supported type is used.

Supported Connected System Types (Current Registry)

The source-type registry currently supports these secret types:

• azure data lake
• postgres
• snowflake
• tds (SQL Server)
• azure event hub
• aws s3
• delta sharing

These are the types that can currently drive the source-add experience through registered handlers in Data Studio.

Connector-Specific Authoring Behavior

Connected systems are not a single generic form in ODA. Each supported type provides connector-specific UX and checks. For example:

• Delta Sharing presents guided selection for share -> schema -> table, supports previewing files and estimated row counts, allows selecting specific files, and can fetch/refresh schema before save.
• Postgres exposes database/schema/query inputs and includes a built-in Test action so users can validate connectivity and query execution before saving the source.

This connector-aware behavior reduces misconfiguration by validating required fields per source type before source nodes are persisted.

Practical Guidance for Users

• Create and maintain the required account secret first, then use it as a connected system in Data Studio.
• Choose a connected system whose secret type matches a supported source handler.
• Use connector-specific test/preview actions (where available) before saving.
• If you see an unsupported secret-type message, switch to a supported secret type or ask an administrator to provision the correct integration secret.