# Workflows | Docs - nodulz

Source: https://nodulz.com/docs/workflows

Language: en

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](/docs/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](/docs/nodes/manual): build and test with controlled input, without waiting for an external service.
- [Webhook](/docs/nodes/webhook): receive a request when a caller can reach your instance.
- [Schedule](/docs/nodes/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](/docs/nodes/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](/docs/nodes/filter) from processing them with a [loop](/docs/nodes/loop_over_items). **Loop** processes each item or batch; **Done** continues after iteration finishes. [Process a list](/docs/working-with-lists) 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](/docs/expressions) covers types, lists and missing values.

## Call another workflow

Use [Call Workflow](/docs/nodes/call_workflow) for reusable processing with fixed steps, such as normalizing a request before saving it. The target is a published [Workflow Event](/docs/nodes/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](/docs/nodes/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](/docs/nodes/call_agent) reuses an accessible specialist.

To answer questions from documents, distinguish two processes:

1. **Indexing**: [load](/docs/nodes/ai_document_loader) documents, [split](/docs/nodes/ai_recursive_text_splitter) them, create [embeddings](/docs/nodes/ai_embeddings) and save them in a vector store.
2. **Question**: embed the question with the same model and dimensions, [retrieve](/docs/nodes/ai_vector_store_retriever) useful passages, then supply those passages to [document questions](/docs/nodes/ai_document_qa).

The [simple store](/docs/nodes/ai_simple_vector_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](/docs/executions).

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

> [!WARNING] An HTTP response does not prove workflow success
>
> A webhook configured to respond immediately may have replied before a step failed. Check the final execution status and the result in the destination service.

To diagnose a difference between a test and a real execution, see [troubleshooting](/docs/troubleshooting).

## Explore further

- [Features - nodulz](https://nodulz.com/product/overview)
- [Node catalog - nodulz](https://nodulz.com/product/catalog)
- [MCP server - nodulz](https://nodulz.com/product/mcp)
- [Pricing - nodulz](https://nodulz.com/pricing)
- [Use cases and workflow automation - nodulz](https://nodulz.com/use-cases)
- [Choose what your workflows can do. - nodulz](https://nodulz.com/compare)
- [Documentation - nodulz](https://nodulz.com/docs)