Workspace¶

The Workspace is the primary SchemAlign build area. This is where integrations are designed, reviewed, tested, and run.

Most users will spend the majority of their time here.

What happens in Workspace¶

Workspace is where teams compose integration logic using SchemAlign's three primary node categories: source, compose, and destination. A typical pipeline may include:

source compose SQL logic destination runtime values artifacts run review

The canvas should make it clear how data moves, where logic lives, and what each step contributes to the integration.

When a pipeline runs, SchemAlign uses the graph to execute work asynchronously. Multiple pipeline runs can be active at the same time, and within a single run, independent branches can progress as soon as their upstream dependencies are satisfied.

Core Workspace activities¶

Build pipelines¶

Add and configure source, compose, and destination nodes for a specific integration workflow. Transformations, including SQL-centered logic, live within the appropriate compose pattern rather than as a separate top-level node type.

Transform with SQL¶

Use SQL-centered transformation patterns that are easier for many technical teams to read, review, and maintain.

Use runtime values¶

Reference explicit named values such as {{current_term}}, {{sysdate}}, or future upstream-published values in supported fields.

Review runs¶

Run a pipeline, inspect results, review artifacts, and trace errors back to the node or configuration that produced them.

Mental model¶

A Workspace pipeline should be readable as a story:

Get data from a source.
Prepare or transform it through compose logic and SQL-centered patterns.
Write, store, or send the result to a destination.
Review the run history and artifacts.

Workspace security and organization boundaries¶

Workspace content is scoped to the active organization. Pipelines created in one organization are isolated from other organizations and cannot be read, reused, or shared across organization boundaries by default.

This isolation helps keep functional-area integration logic, service-account usage, runtime values, artifacts, and run history separated between organizations.

Global organization content is the exception. Items intentionally created in the global organization can be shared for use across organizations when global sharing and access rules allow it. SQL tables in the global schema can also be referenced from organization-scoped SQL by qualifying the schema name:

select *
from global.<table_name>;

Use global objects for shared reference data, reusable platform-level resources, or centrally managed tables that are intended to support multiple organizations. Use organization-scoped objects for area-specific workflows, pipelines, credentials, runtime data, and operational outputs.

Use global resources intentionally

Global objects are designed for shared use. Do not place area-specific pipeline logic, sensitive operational outputs, or organization-specific data in global resources unless that sharing is intentional and approved.

Workspace is the bread and butter

Overview helps users understand what is happening, but Workspace is where SchemAlign's integration value is built.