> ## Documentation Index
> Fetch the complete documentation index at: https://flowdrop.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# What is a workflow?

> Understand the core mental model behind FlowDrop before writing any code.

export const AsciiDiagram = ({children}) => {
  return <div className="ascii-diagram">{children}</div>;
};

FlowDrop is a **visual workflow editor** — a UI component that lets users build
directed graphs of processing steps by dragging, connecting, and configuring
nodes on a canvas.

Before diving into code, it's important to understand the mental model.

## The four primitives

Every workflow in FlowDrop is built from four core concepts:

### Nodes

A **node** is a single step in the workflow. It represents an action, decision,
or data transformation — for example, "Send an HTTP request", "Run an LLM
prompt", or "Route based on condition".

Each node has:

* A **type** that determines its visual appearance (default, simple, square, tool, gateway, terminal, idea, note)
* **Metadata** describing its name, icon, category, and capabilities
* **Configuration** — user-editable settings defined by a JSON Schema

### Edges

An **edge** is a connection between two nodes. It defines the flow of data or
control from one step to the next.

Edges have **categories** that determine their visual style and semantic meaning:

* **data** — standard data flow (default)
* **trigger** — event-based activation
* **tool** — tool invocation from an agent
* **loopback** — feedback loops

### Ports

A **port** is a typed connection point on a node. Nodes have **input ports**
(receiving data) and **output ports** (sending data). Ports represent the
**runtime data** that flows between nodes during execution — the actual payloads
that one node passes to the next.

Each port has a **data type** (e.g., `string`, `json`, `file`, `trigger`).
FlowDrop enforces **type-safe connections** — you can only connect ports with
compatible data types.

For example, an LLM node might have:

* An input port of type `string` that receives the user's prompt
* An output port of type `json` that emits the model's response

Ports are **unique to each connection** — every edge carries its own data
between a specific pair of nodes.

### Config

**Configuration** is different from ports. While ports carry runtime data that
varies with each execution, config holds **shared settings** that apply
consistently across all runs of the workflow.

Config values are defined by a [JSON Schema](/guides/config-schema) and edited
through a form UI when users click on a node. They control *how* a node behaves
rather than *what* data it processes.

For example, the same LLM node might have config fields for:

* **Model name** — which LLM to use
* **Temperature** — how creative the responses should be
* **Max tokens** — the response length limit

These values don't change from request to request — they're decisions the
workflow author makes once, and every execution of the workflow uses them.

<Tip>
  **Ports vs. config — a quick rule of thumb.**

  **Ports** = "What data flows through at runtime?" (dynamic, per-execution)

  **Config** = "How is this node set up?" (static, set once by the workflow author)
</Tip>

## How it all fits together

<Note>
  **Ports carry runtime data; config holds settings.**

  Each node has typed **ports** for runtime data and **config** for
  workflow-level settings. An **edge** connects an output port to an input port,
  defining data flow. Config values stay the same across executions; port data
  changes every time.
</Note>

A workflow is a **graph**: nodes are the vertices, edges are the connections,
ports define where connections attach, and config controls what each node does.

## What FlowDrop does (and doesn't do)

FlowDrop is a **frontend editor**. It handles:

* Visual canvas with drag-and-drop, zoom, pan
* Node palette and sidebar for discovery
* Connection drawing with type-safe port validation
* Configuration forms generated from JSON Schema
* Workflow serialization to JSON
* Undo/redo, auto-save drafts, import/export

FlowDrop does **not** handle:

* **Execution** — It doesn't run your workflows. You need your own backend execution engine.
* **Storage** — It calls your REST API to persist workflows. You provide the database.
* **Business logic** — Node behavior is defined by your backend, not by FlowDrop.

Think of it this way:

> **FlowDrop owns the UI. You own the logic.**

FlowDrop gives users a beautiful way to *design* workflows. Your backend gives
those workflows *meaning*.

## The frontend–backend contract

FlowDrop communicates with your backend through a REST API. The contract is simple:

1. **Your backend tells FlowDrop what nodes exist** — by serving node metadata (name, ports, config schema)
2. **Users build workflows visually** — FlowDrop handles all the UI
3. **FlowDrop sends the workflow JSON to your backend** — for storage and execution

<AsciiDiagram>
  ```
  ┌──────────────┐   REST    ┌──────────────┐
  │   FlowDrop   │───API────▶│ Your Backend │
  └──────────────┘           └──────────────┘
  ```
</AsciiDiagram>

For a detailed breakdown of this architecture, see [Architecture Overview](/concepts/architecture-overview).

## When to use FlowDrop

FlowDrop is a good fit when you need:

* A **visual, no-code interface** for building multi-step processes
* **AI agent workflows** with branching, tool use, and human-in-the-loop
* **Data pipelines** with configurable transformations
* **Automation builders** where non-technical users define business logic
* **Any application** where users need to compose processing steps visually

## Next steps

* [Architecture Overview](/concepts/architecture-overview) — how all the pieces fit together
* [Installation](/docs/quickstart) — get FlowDrop into your project
* [Tutorial](/tutorial/01-embedding-the-editor) — build your first workflow editor step by step