Concepts Overview

The Big Picture

The platform is a visual workflow automation engine. You define what your data looks like (schemas), then define what happens to that data (processes). Processes are triggered by events (emails, webhooks, schedules), execute a graph of nodes, and produce outputs.

Schema (data shape)
  └── Data Block (entity)
        └── Data Point (field)

Process (workflow)
  ├── Input Node (trigger)
  ├── Processing Nodes (transform, extract, decide)
  ├── Output Node (deliver result)
  └── Edges (connections between nodes)

Execution (single run of a process)
  ├── Node States (status of each node)
  ├── Data Bucket (all intermediate results)
  └── Execution History (audit trail)

Schemas

A schema is a reusable data model. It defines the structure of information your workflows process.

Data Blocks

A schema contains one or more data blocks. Each data block represents an entity or message type — think of it as a table or a JSON object definition.

Example: A Steel Order schema might have two data blocks:

• Order Request — the incoming request fields
• Quote — the outgoing quote fields

Data Points

Each data block contains data points (fields). Every data point has:

Schema Edges

Edges connect data blocks within a schema. An edge can have coupling functions that define how data transforms from one block to another. This is used during schematization when extracting related data blocks from the same input.

See Schemas In-Depth for full details.

Processes

A process is a directed acyclic graph (DAG) of nodes connected by edges. It defines a workflow that transforms input data into output.

Nodes

Nodes are the building blocks of a process. Each node has:

• A type (input, output, script, ML model, schematization, conditional, loop, etc.)
• A label (display name, used in template references)
• A config (type-specific settings stored as JSON)
• A position (x, y coordinates on the canvas)

Edges

Edges connect one node's output port to another node's input port. Data flows along edges. A node can have multiple input edges (aggregating data from several upstream nodes) and multiple output edges (fanning out to several downstream nodes).

Process Lifecycle

Created → Editing → Locked → Running → Stopped
                  ↑                    │
                  └────────────────────┘

• Editing: Add/remove/configure nodes and edges
• Locked: Prevents accidental changes while running in production
• Running: Input listeners are active, waiting for triggers
• Stopped: Listeners shut down, no new executions start

See Processes In-Depth for full details.

Node Types

Nodes fall into five categories:

Input Nodes (Triggers)

Start a process execution when an event occurs.

Processing Nodes

Transform, analyze, or route data.

Output Nodes

Integration Nodes

Flow Control Summary

See Node Reference for the complete configuration reference.

Execution

An execution is a single run of a process. When a trigger fires, the execution engine:

• Takes a snapshot of the process graph
• Initializes all node states to pending
• Starts executing nodes whose dependencies are satisfied
• Propagates data along edges as nodes complete
• Records the final status and all node outputs

Execution Statuses

Node Statuses

Data Bucket

During execution, every completed node's output is stored in a data bucket. Any downstream node can reference any upstream node's output through templates. This is what makes {{input["Node Label"]["field"]}} work.

See Execution Engine for the full execution model.

Templates

Templates are the glue between nodes. They let you reference upstream data in node configurations using the syntax:

{{input["Node Label"]["field_name"]}}

Templates are resolved just before a node executes. The engine scans the node's config JSON for {{...}} patterns and replaces them with actual values from the data bucket.

Built-in Functions

See Data Flow and Templates for the full template reference.

Organizations and Access

Every resource (schema, process, dashboard, etc.) belongs to an organization. Users can be members of multiple organizations and switch between them.

Permissions are controlled through access tags. Each tag grants read or write access to a system (e.g., process:write, schema:read).

API keys allow programmatic access to trigger processes. Each key has a rate limit, optional expiration, and optional restriction to specific process IDs.

See Authentication and Access for full details.

Collections

Collections are folders for organizing schemas and processes. Collections can be nested and a single schema or process can belong to multiple collections.

Versions

Process versions are named snapshots of a process at a point in time. A version captures the full graph (nodes, edges, configs) so you can restore to any previous state.

See Collections and Versions for details.

Testing

Test cases define expected inputs and outputs for a process. You can create test cases with predefined input data, define expected output schemas for validation, run tests individually or in batches, and track test run history with pass/fail status.

See Testing for details.

Concept Relationships

Organization
 ├── Users (with access tags)
 ├── API Keys
 ├── OAuth Accounts
 ├── Service Accounts
 │
 ├── Schemas
 │    ├── Data Blocks
 │    │    └── Data Points
 │    └── Schema Edges (with coupling functions)
 │
 ├── Processes
 │    ├── Nodes (typed, configured)
 │    ├── Edges (connections)
 │    ├── Versions (snapshots)
 │    ├── Test Cases
 │    └── Executions
 │         ├── Node States
 │         └── LLM Traces
 │
 ├── Schema Collections
 ├── Process Collections
 │
 └── Dashboards
      ├── Tabs
      ├── Grid Components
      └── Database Connections