Data Layers Overview

Data layers are the data assets available to your organization in Kogenta Connect. They represent tables, views, and uploaded files that you can reference in your workflows and use as building blocks for analysis.

Source types

Data layers come from two sources:

Connected tables

These are tables and views imported from your data source connections. When a data source is configured, you can browse its catalogs and schemas, then import specific tables as data layers. Connected data layers reference the live data in your external database.

Uploaded files

You can also create data layers by uploading files directly. Supported formats include CSV and TSV. Uploaded file data layers are stored within the platform and can be queried just like connected tables.

What data layers provide

Each data layer includes:

A schema definition - the columns and their data types, so you know what fields are available
Metadata - name, description, tags, and the number of rows
Folder organization - data layers can be arranged into folders for easy browsing

Ownership

Data layers can be:

Owned by your organization - created and managed by your team
Shared with your organization - platform-level data layers made available to you by Kogenta

You can filter data layers by ownership in the Data Layers view to find what you need.

Virtual names

Every data layer has a virtual name that you use to reference it in workflow SQL queries. The virtual name is built from the data layer's folder path and table name, using dot notation:

Folder	Table name	Virtual name
(no folder)	`dim_customers`	`dim_customers`
`places`	`dim_divisions`	`places.dim_divisions`
`places > regions`	`dim_regions`	`places.regions.dim_regions`

Virtual names let you reference data in a clean, organized way without needing to know the underlying database paths. Virtual names are handled automatically when your query runs.

If two data layers share the same table name but live in different folders, you must use the folder-qualified virtual name to avoid ambiguity. For example, if both acme.dim_places and legacy.dim_places exist, you cannot use just dim_places - you need the full virtual name.

Using data layers in workflows

When writing SQL in workflows, you reference data layers by their virtual name:

SELECT *
FROM places.dim_divisions
WHERE region = {{region}}

The workflow editor provides autocomplete for virtual names, showing available data layers and their columns as you type. This makes it easy to discover and reference the data you need without leaving the editor.