Workflow

A Workflow is LanSphere’s single-run automation app: given one input, it executes automatically along the node flow you orchestrated, straight through to the output — no human interaction along the way.

This article covers Workflow use cases, canvas operations, the three trigger types, connections and variable references, environment variables, debugging, and saving & publishing. It is for developers building automated flows. For per-node configuration details, see “Node Reference.”

Use Cases

Workflows fit “one input, one output” automation. Typical scenarios:

Data processing: Parse, extract, aggregate, and format input text, files, or structured data.
Scheduled jobs: Run automatically on a recurring schedule — e.g., collect data or generate reports on a timer.
Batch jobs: Apply the same processing logic to each item in bulk — e.g., batch review, batch rewriting.
API orchestration: Chain multiple system APIs and internal tools into a single call across systems.

Creating a Workflow

Click “New Project” at the top of the left menu.
Choose the app type “Workflow” in the pop-up.
Fill in the app name (required, 1–30 characters; Chinese characters, upper/lowercase letters, digits, and hyphens only). Description is optional (up to 300 characters); custom avatar upload supported.
Confirm to enter the “App Development” page and start orchestrating on the canvas.

Tip: Besides blank creation, you can also create from the Template Store or import a DSL file. Legacy Agent DSL files are rejected on import — create those in the Agent module instead.

Canvas Operations

A Workflow is orchestrated on a visual canvas. Basic operations:

Add nodes: Click a node in the node list to add it to the canvas. Nodes are added by clicking only — drag-and-drop is not supported.
Find nodes: The node list can be expanded/collapsed and searched by fuzzy name match to quickly locate a node when there are many.
The “Input” node is globally unique: A Workflow allows only one “Input” node; once it is on the canvas, the list hides it automatically.
Zoom: Use the zoom-in/out buttons at the bottom of the canvas.
Undo and redo: Available at the bottom of the canvas, covering node additions/removals and edits inside nodes.
Change history: “Change History” at the bottom of the canvas shows the canvas’s modification records.

Trigger Nodes: Three Types

Every Workflow starts from a trigger. There are three trigger nodes:

Trigger	How it fires and what it is for
Input	Manual trigger. The user fills in input parameters at run time — the most common starting point, ideal for form-style single-run jobs
Scheduled Trigger	Automatically triggers the Workflow on a recurring schedule — for unattended jobs like scheduled collection and scheduled aggregation
Webhook Callback	Generates a callback URL; an external system calls the URL to trigger the Workflow — for event-driven integration with other systems

Connections and Node Configuration

Nodes pass data over connections: the output produced by one node can be referenced as an input variable in a later node’s configuration, chaining nodes into a complete flow. For example, the payload fetched by an “HTTP Request” node can be fed into an “LLM” node for summarization, then returned by an “Output” node.

Click a node on the canvas to open its configuration panel and finish parameter settings and variable references as prompted. For the full “what it is, what to configure, what it outputs” of every node, see “Node Reference.”

Tip: Connections and variable references are the heart of Workflow orchestration. Before wiring anything, get clear on where each node’s input comes from and who consumes its output.

Tool-Type Nodes

Beyond the built-in function nodes, the node list offers four tool-type node categories for calling capabilities inside and outside the platform:

System Plugins: Call installed and enabled System Plugins.
Workflow: Call Workflows published as components (from “Collaboration Components → Workflow”) to reuse flows.
MCP: Call tools provided by services added under “MCP Services.”
Custom Tools: Call Custom Tools created in “Plugin Management.”

Clicking any of the four opens the corresponding tool-list pop-up; pick the tool to call and the node is added.

Environment Variables

Environment Variables are app-level dynamic parameters for values that vary by environment — service addresses, secrets, and the like — referenced uniformly by nodes in the flow, so you do not repeat them in multiple nodes.

An Environment Variable can be marked as a “secret variable”: once set, its value is masked with asterisks — ideal for keys and other sensitive info.

Tip: Service addresses and secrets usually differ across deployment environments (e.g., test vs. production). Always pass them in through Environment Variables instead of hardcoding values into node configurations.

Variable Inspector

The Variable Inspector checks variable definitions, type matching, and reference validity before a run, catching problems like “referenced a variable that doesn’t exist” or “variable type mismatch” early. Run it after every significant change.

Debugging

Workflows support two levels of debugging:

Single-node debug: Runs only the selected node to verify its configuration — good for isolating issues one by one.
End-to-end debug: Runs the entire flow from the trigger node to verify the full execution.

Recommended order: single-node debug the key nodes first to confirm inputs and outputs, then run the end-to-end debug. After a run, each node shows its input, output, and error info to help locate the failing step; past runs are available in “Debug History” for comparing results across versions.

Checklist

Before publishing, the system automatically runs a Checklist over the flow’s configuration completeness and logic. Fix each item as prompted and publish only when everything passes.

Saving and Publishing

Hovering over the “Save” button at the top right of the canvas always shows three options:

Action	Description
Save	Save as a draft, visible only to you; drafts cannot be published to the App Square
Publish to App Square	Saves the latest content and lists the app in the App Square, visible and usable by everyone on the platform (including Viewers)
Publish as Component	Visible for the Workflow type only. After saving, configure the component info to become a Workflow component, syncing automatically to “Collaboration Components → Workflow” for other apps to call

Note: “Publish as Component” and “Publish to App Square” are mutually exclusive, and components published through “Publish as Component” are not listed in the App Square.

Beyond the App Square, a Workflow can also open a web link, API access, and more in the “Publishing Channels” tab. Workflows cannot be published as Lansenger AI Assistants — for a conversational app facing Lansenger end users, use Chatflow or Agent. See “Publishing Channels” for the full picture.

App States

A Workflow moves through these states from creation to going live: Created (unsaved) → Saved (draft, visible only to you) → Published (App Square / component — channels are independent) → WebApp live (once a web link is enabled; coexists with the publishing channels). “Version Management” in the Publishing Channels tab records every published version’s release notes, publisher, and time, and supports looking back.

“Node Reference”: Purpose, key settings, and outputs of every node.
“Chatflow”: The app type for multi-turn interaction with context memory.
“Publishing Channels”: The full flows for web link, API access, App Square, and Publish as Component.
“Collaboration Components”: Reusing and calling Snippets, Workflow components, and Agent components.