Workflows

Guides
On this page

A workflow describes how to process input: what starts it, which steps run, what decisions to make and what result to produce. For a complete first example, follow Getting started.

Define the result before adding nodes

Choose a specific case, such as “receive a request and create a contact”. Write down a sample input, required fields, expected action and what should happen if the contact already exists. These expectations become your checks.

Start with one request and a test destination. Then add empty, invalid and already processed cases. For an action that writes to a service, choose a stable request key so you can detect duplicates.

Triggers

  • Manual: build and test with controlled input, without waiting for an external service.
  • Webhook: receive a request when a caller can reach your instance.
  • Schedule: poll a service or run processing at a defined time.
  • Application event: use the provider’s trigger when it matches the event you need. Its page describes access requirements and delivery behavior.

A manual processing test does not validate webhook delivery, a provider subscription or a schedule. Check the trigger with a real event after publishing as well.

Connections and branches

Execution connections define the order of steps. IF outputs correspond to true and false: connect each case you want to handle. Inspect the condition result if a branch does not run.

For a list, distinguish selecting items with Filter from processing them with a loop. Loop processes each item or batch; Done continues after iteration finishes. Process a list lets you reproduce this flow without an external service.

An AI agent’s component ports supply its model, memory and tools. Connecting a tool to an agent does not run it unconditionally: the model decides when to call it during the task.

Configure data

Run steps in order and select upstream data through mapping. input remains the trigger input; nodes.<name> reads a specific output. Node options can change that output: check Body only for HTTP and Mapped fields only for Edit fields in particular.

Use a preparation step to name the fields expected by the destination explicitly. This makes the workflow easier to read and avoids sending a full API response when only two fields are needed. The expression guide covers types, lists and missing values.

Call another workflow

Use Call Workflow for reusable processing with fixed steps, such as normalizing a request before saving it. The target is a published Workflow Event. The call shares context and outputs within the same run.

Define the input expected by the target and test a call with a missing field before replacing an existing sequence. Reuse still requires checking the owner’s access.

Agents and document retrieval

For a task that needs to choose tools based on a request, use an AI agent. Start with a model and one read tool, a precise goal and a limited number of turns. Then add memory or write actions as needed. Call an agent reuses an accessible specialist.

To answer questions from documents, distinguish two processes:

  1. Indexing: load documents, split them, create embeddings and save them in a vector store.
  2. Question: embed the question with the same model and dimensions, retrieve useful passages, then supply those passages to document questions.

The simple store stays in execution data. Choose external storage to reuse an index in another run. Check retrieved passages before adjusting the prompt: without relevant passages, a fluent answer does not prove retrieval works.

Test and publish

Before publishing, verify these outcomes:

  • Normal input produces the expected fields and action.
  • Incomplete input takes an identifiable rejection branch.
  • Every decision branch has run at least once.
  • Retrying the same event does not create an unwanted duplicate write.
  • A failure leaves a useful message in execution history.

Publish to activate external or scheduled triggers. After changing their configuration, publish again, generate a real event and find the corresponding run in history.

To diagnose a difference between a test and a real execution, see troubleshooting.