Workflow Nodes

A node is the smallest processing unit in a workflow. It receives explicit inputs and parameters, performs one transformation, and passes the result to downstream nodes, Catalog objects, or runtime records.

Do not think of nodes as icons that can be stacked arbitrarily. A reliable process first makes each node’s inputs, outputs, and failure boundaries clear; connections and automation come afterward.

Node Panel and Availability

The workflow node panel displays system nodes from the WorkItem catalog available in the current workspace and groups them by function. The nodes you actually see also depend on model configuration, backend capabilities, object permissions, and role permissions.

This page therefore explains node categories, selection principles, and composition methods. If a node does not appear in the current panel, first check the related resources, models, permissions, or workspace configuration rather than assuming that manually editing the canvas can bypass these constraints.

Node Overview

Category	Common nodes	Problem solved	Common downstream destination
Boundary nodes	Start, End	Mark the entry and endpoint of a process	All processing paths
Data I/O	Read Table, Read Volume, Import, Write Table, Write Volume, API Call	Move data into or out of a processing chain	Parsing, SQL, extraction, Catalog
Multimodal processing	Document, image, audio, and video parsing; cleaning; chunking	Turn raw content into computable content units	Extraction, embedding, indexing, writing
Retrieval and AI	Embedding, knowledge indexing, structured extraction, model inference	Generate semantic representations, retrievable content, or structured fields	Knowledge bases, result tables, agent consumption
Code processing	SQL processing	Perform governed SQL transformations and materialize results	Target tables, subsequent nodes
Governance	Lineage registration	Explicitly record asset and processing relationships	Catalog lineage and impact analysis
Process control	Parallel, conditional branch, loop, subworkflow	Express routing, concurrency, repetition, and reuse	Multiple processing paths
Extensions	Custom operator	Encapsulate a team’s reusable processing logic	Any compatible downstream node

First Understand Input—Processing—Output

All nodes can be understood through the following model. During configuration, confirm these three items one by one instead of guessing from the node name alone.

Upstream assets or parameters → Node processing rules → Data results, status, or side effects → Downstream nodes / Catalog / job records

Dimension	What to confirm	Common mistake
Input	Data type, table/volume location, file scope, fields, parameters, permissions	Selecting a same-named object outside the current project; incompatible upstream output shape
Processing	Parsing policy, SQL, model, chunking rule, write policy, or control condition	Treating default parameters as business rules; ignoring model or external-service constraints
Output	Result structure, target object, write mode, downstream compatibility	Seeing data only in temporary results without persisting the business result
Failure	How timeouts, empty input, invalid files, or insufficient permissions are exposed	Swallowing failures so downstream receives incomplete or inexplicable data

Before connecting nodes, determine whether their data contracts match. For example, document-parsing output is suitable for cleaning, chunking, or extraction nodes, while aggregation, joins, and write-back for structured tables are generally better suited to SQL processing nodes.

Boundary and Data I/O Nodes

Start and End nodes define the scope of a workflow. A Start node accepts no upstream connection, and an End node produces no further output. They help readers and the runtime distinguish a complete process from a local processing fragment.

Data I/O nodes bring governed data into, out of, or back into the asset hub. Model reading and writing separately: a read node states “where and in what form data is obtained,” while a write node states “where the result is written and under what rules it is saved.”

Node direction	Common capability	Suitable scenario	Configuration focus
Read structured table	Read data from a Catalog table	Cleaning, filtering, joining, aggregation, or SQL transformation	Database/table, fields, filters, read permissions
Read volume/file	Obtain files or content from a Catalog volume	Document, image, audio, or video processing	Volume, file scope, path, format, entry parameters
Import data	Bring supported external or object-storage data into the processing chain	Object storage such as S3 into a workspace asset chain	Connection information, source, target, credentials, permissions
Write table	Materialize structured results as a Catalog table	Metric tables, extraction result tables, normalized datasets	Target table, field mapping, write mode, idempotency policy
Write volume	Write file or content results back to a governed location	Parsed artifacts, derived document content, file output	Target volume, naming rules, overwrite/append policy
API call	Send data to or obtain results from a service API	Connect to authorized business services	Request parameters, authentication, response structure, error handling

For critical outputs, use clear business object names and stable locations. This lets downstream knowledge bases, SQL, exports, and collaborators reference the same result instead of relying on a particular job’s temporary context.

Multimodal Processing Nodes

Multimodal nodes turn raw content into content units that subsequent steps can process. They are especially suitable for file-based assets, but their inputs, processing, and outputs should be as explicit as in structured processing.

Parsing: First Turn Content into a Usable Representation

Available parsing capabilities include documents, images, audio, and video. Select a parsing node according to the input’s actual media form and business goal, not merely its file extension.

Node	Goal	Common subsequent path
Document parsing	Identify document text, layout, tables, images, and content structure	Cleaning, chunking, field extraction, embedding, writing back
Image parsing	Identify text, regions, or structured content in images	Field extraction, multimodal retrieval, result persistence
Audio parsing	Turn audio into processable text or content units	Cleaning, chunking, summarization, retrieval, or extraction
Video parsing	Extract processable content and time-related information from video	Retrieval, summarization, extraction, or knowledge preparation

When configuring a parsing node, first confirm the input file scope, applicable parsing capability, content scope, and output purpose. To improve recognition quality, then adjust model, layout, content-repair, or reading-order options provided by the current interface.

Do not treat parsing results as final knowledge. Parsing solves “reading it”; subsequent cleaning, chunking, extraction, and validation determine whether the content is suitable for retrieval, summarization, or citation by an agent.

Cleaning and Chunking: Turn Content into Stable Semantic Units

Cleaning nodes remove invalid content, normalize text, or repair obvious noise. Chunking nodes split continuous content into manageable, indexable, and locatable fragments, establishing suitable granularity for embedding, retrieval, and information extraction.

Design question	Recommendation
How large should chunks be?	Aim for each chunk to express complete business meaning independently; do not maximize character count merely for convenience
Should titles and sources be retained?	Retain metadata that helps locate and explain results, such as document name, page number, section, or time segment
Where should cleaning occur?	Remove repeated headers, garbled text, and meaningless whitespace before chunking so noise is not propagated across fragments
How should output be validated?	Inspect a sample of chunk boundaries, source information, and key content for incorrect splits or omissions

For content requiring highly trustworthy citations, retain source-location information through to the output. Then, when a knowledge base or agent returns a result, the team can verify its basis in the original file or passage.

Retrieval, Extraction, and Model Nodes

These nodes turn processed content into retrievable or consumable business results. They usually depend on configured models, indexes, or knowledge assets, so check both model availability and target-object permissions.

Capability	Purpose	Typical output
Text embedding	Map text or content units to semantic vectors	Vector representations, retrieval inputs, or index data
Knowledge index construction	Organize content and index configuration into retrievable assets	Knowledge-base indexes and consumable content
Structured information extraction	Extract information from content according to field definitions	Table fields, JSON structures, or business records
Model inference	Generate, classify, evaluate, or transform content	Text, labels, structured results, or downstream parameters

A model node should specify its input scope, prompt or field constraints, selected model, and expected output. For critical fields such as contract numbers, amounts, dates, and classification labels, add format, null, or business-rule validation before writing. Do not consider a value correct merely because the model returned it.

Before building a knowledge index, confirm that content has undergone necessary parsing, cleaning, and chunking. An index cannot automatically repair input-quality problems; incomplete input or poor chunk boundaries directly affect later retrieval and agent answers.

SQL Processing Nodes

A SQL processing node brings SQL transformations into a workflow so structured transformations can share one processing chain with file parsing, model extraction, and result write-back.

SQL nodes are suitable for filtering, projection, joins, aggregation, cleaning structured fields, and materializing query results as target tables. They do not replace the SQL editor for temporary exploration; they are for established SQL logic that must run repeatedly.

Configuration item	Purpose
SQL	Defines query or transformation logic and should clearly reference input and target objects
Parameters	Let the same processing logic use different input conditions across runs
Timeout	Sets a manageable execution boundary for potentially long-running queries
Output table	Specifies a target table when a SELECT result must be persisted
Write mode	Controls whether the target table is created, replaced, or appended
Materialization policy	Query results can currently be materialized as tables; configure this explicitly with the output table and write mode

When SQL results must be written to a target table, specify the output table, write mode, and materialization method together. Common write modes include create, replace, and append. Before choosing, determine whether a rerun would create duplicate records or overwrite existing business results.

Validate complex SQL in the SQL editor before placing it in a workflow. This lets you first confirm table schemas, field meanings, and result correctness, then preserve it as an executable production step.

Process Control Nodes

Process control nodes do not primarily change business data. They determine when different processing paths execute, how they join, or how they repeat. They use native runtime control semantics and should not be connected arbitrarily like ordinary data nodes.

Structure	Suitable situation	Key point
Parallel	Multiple independent processes can start simultaneously	Branches should be independent; join before steps that truly depend on every result
Conditional branch	Different inputs or states require different processing paths	Conditions must be explainable, and branches must cover critical business outcomes
Loop	A group of content must be processed repeatedly according to rules	Use the native loop structure; do not create a cycle with ordinary connections
Subworkflow	A stable process fragment is reused in multiple larger processes	Clearly define the subprocess inputs, outputs, and version boundary first

Ordinary canvas edges cannot form a direct cycle, preventing a runtime dependency order that cannot be determined. For repetition, parallelism, or conditional processing, use the corresponding structural node to keep both the canvas and runtime records readable.

Current parallel and conditional structures use native join semantics and do not need an extra “join decision” processing node. Connect downstream steps at the correct position after the structure completes, and validate every path’s inputs and outputs in a test run.

Lineage Registration Nodes

A lineage registration node incorporates processing inputs, outputs, and transformation relationships into asset tracing. It is suitable for critical data products that must clearly explain “where the result came from, what processing it underwent, and who consumes it.”

Lineage does not replace job diagnostics. Lineage answers questions about asset dependencies and impact scope. To see whether a run succeeded, which node failed, and how long it took, use Jobs and Run and Debug.

Custom Operators

When a team has stable, reusable processing logic, it can encapsulate that logic as a custom operator and add it to workflows like a system node. Custom operators are suitable for extracting validated domain rules, SQL logic, or code implementations from an individual process.

When to encapsulate	When not to rush
Multiple workflows need the same input/output logic	The logic still changes frequently and inputs/outputs are not stable
A clear version, owner, and test boundary are needed	It is only a one-off experiment
Copying and manual consistency need to be reduced	Dependent resources, permissions, or exception handling are not yet confirmed

When using a custom operator, review its name, description, inputs, outputs, and available versions. Before upgrading or switching versions, validate results in a copy or test process; do not assume version changes have no effect on existing data results.

Operator creation, resource management, and external-service publishing belong to the asset-management boundary of Catalog. This page focuses on placing an available operator in the correct processing chain.

Four Design Principles for Combining Nodes

1. Give Each Node One Stable Responsibility

Keeping reading, parsing, cleaning, extraction, and writing separate makes it easier to identify which step caused an error. Packing many business rules into one node may shorten the canvas but makes reuse, testing, and troubleshooting difficult.

2. Materialize Results at Critical Boundaries

For expensive steps, quality-sensitive steps, or steps requiring review by multiple people, write results to an explicit Catalog object. This avoids repeating all upstream work after a failure and gives downstream systems a stable asset to reference.

3. Follow Uncertain Steps with Explicit Checks

Model inference, external APIs, and complex-format parsing all involve uncertainty. Add result validation, null handling, or a manual review entry point afterward; do not let unchecked output overwrite critical business tables.

4. Preserve Business Meaning for Every Edge

A connection should mean “this node must depend on that result,” not merely make the canvas flow from left to right. If two steps have no data or sequencing dependency, reconsider whether they belong in the same process.

Common Misconceptions

Misconception	Why it is risky	Better approach
Use one large node for everything	Inputs, outputs, and failure points are invisible, making reuse and troubleshooting difficult	Split responsibilities into reading, processing, validation, and writing
Build a knowledge index immediately after parsing	Noise, duplication, and incorrect chunks enter downstream retrieval	Clean first, inspect samples, and establish a chunking policy
Put exploratory SQL directly into production	Unvalidated SQL may write incorrectly or create costly queries	Validate it in the SQL editor first, then formalize it as a SQL node
Draw a loop with ordinary edges	Graph structure and runtime dependencies become indeterminate	Use a loop control structure
Manually edit the DSL when a node is missing	This may bypass resource, permission, or backend-catalog constraints	Check available resources and permissions in the current workspace first

Next Steps

• To move from node design to a complete process, read Workflow.

• To validate node parameters, scheduling, and failure handling, read Run and Debug.

• To combine nodes into typical structured, multimodal, or knowledge-base processing chains, read Processing patterns.