Skip to content
ADL Docs
Get Started Concepts Using the App Templates Reference

Connections

The Connections screen is where you define the locations where your data lives. A connection represents a database, warehouse, schema, or other data store that your data objects belong to.

What you can do here

Section titled “What you can do here”

Create and manage connections

Section titled “Create and manage connections”
  • Add new connections to your project — one for each database or schema you’re working with.
  • Edit existing connections to update names, connection strings, or other properties.
  • Delete connections you no longer need.
  • Browse all connections in your project.

Configure connection properties

Section titled “Configure connection properties”

Each connection includes:

  • Name — A descriptive label (e.g., “Source System”, “Staging Area”, “Data Vault”).
  • Connection type — What kind of system this is: SQL Server, Snowflake, PostgreSQL, or others.
  • Connection string — The details needed to connect to this data store.
  • Location — The schema, catalog, or database name.
  • Qualifiers — The characters used to quote identifiers (e.g., [ and ] for SQL Server, " for PostgreSQL).
  • Separator — The character used between schema and table names (typically .).

Apply classifications

Section titled “Apply classifications”

You can tag connections with classifications to indicate sensitivity levels or organizational categories.

A typical setup

Section titled “A typical setup”

Most data projects have a handful of connections representing the different layers of the solution:

  • Source — Where the original data comes from.
  • Staging / Landing — A temporary area where source data is loaded before processing.
  • Persistent Staging — A history-preserving staging layer.
  • Integration — Where transformed data is structured (e.g., a Data Vault).
  • Presentation — Where data is served to end users and reporting tools.

You don’t need all of these — just create the connections that match your architecture.

Tips

Section titled “Tips”
  • Set up connections early — Data objects need a connection, so it’s best to create your connections before defining tables and views.
  • Use clear, descriptive names — When you have multiple connections, names like “AdventureWorks Staging” are much easier to work with than “Connection1”.
  • Check your connection type — Templates often generate platform-specific output, so making sure your connection type is accurate helps ensure the right SQL syntax is used.
Section titled “Related”