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

# Workflow Blocks: The Building Blocks of Scout Automation

> Learn how to use Scout workflow blocks — Action, Agent, Condition, Transform, and more — to build powerful, data-driven automations with branching logic.

Blocks are the units of execution in a Scout workflow. Each block takes inputs, performs exactly one job, and produces structured output that downstream blocks can reference. Chain them together and you get a workflow that's easy to read, test, and debug — because every step is isolated and inspectable on its own.

## How Blocks Work

Every block has three parts:

* **Inputs** — values from the workflow's trigger payload or a prior block's output
* **Config** — the block's settings, such as a prompt, a URL, a condition expression, or a transformation rule
* **Output** — a structured result the next block can reference by name

Reference any prior block's output using double-brace syntax:

```
{{ block_id.output }}
```

For example, if you have an LLM block with the ID `classify_ticket`, the next block reads its result as `{{ classify_ticket.output }}`. You can also reference nested fields: `{{ classify_ticket.output.urgency }}`.

Here is a simple three-block chain to illustrate the pattern:

```
Input Block        → accepts {{ inputs.user_query }} from the caller
LLM Block          → uses {{ inputs.user_query }} in its prompt; ID: summarize
Text/Output Block  → shapes the final response using {{ summarize.output }}
```

<Note>
  Name your blocks by what they do, not the tool they use. `fetch_customer` is more readable than `http_1` when you're tracing a failure in the logs six months later.
</Note>

## Block Types

### Input and Output Blocks

<CardGroup cols={2}>
  <Card title="Input" icon="arrow-right-to-bracket">
    Defines the runtime payload fields that callers must provide when triggering the workflow. Every workflow starts with an Input block.
  </Card>

  <Card title="Text / JSON" icon="file-code">
    Shapes or transforms data into a clean output format. Use this to restructure an API response or format a final return value.
  </Card>

  <Card title="HTTP" icon="globe">
    Calls any external REST API and returns the response body. Use this for any API that doesn't have a dedicated integration block.
  </Card>

  <Card title="Save Document to Table" icon="floppy-disk">
    Persists workflow output to a Scout Database Table for later retrieval or search by agents and other workflows.
  </Card>
</CardGroup>

### AI Processing Blocks

<CardGroup cols={2}>
  <Card title="LLM / Reasoning" icon="brain">
    Generates text, answers questions, extracts structured data, or classifies inputs. Use this when the task requires language understanding.
  </Card>

  <Card title="Agent" icon="robot">
    Runs a fully configured Scout agent as a step inside your workflow. The agent uses its own tools, memory, and instructions to complete the task.
  </Card>

  <Card title="Web Search / Scrape" icon="magnifying-glass">
    Pulls live context from the web. Use this to ground an LLM block in current information.
  </Card>

  <Card title="JavaScript" icon="code">
    Runs custom logic when built-in block configuration isn't sufficient. Use this for deterministic transformations that would be overcomplicated in a template.
  </Card>
</CardGroup>

### Control Flow Blocks

<CardGroup cols={2}>
  <Card title="Condition" icon="code-branch">
    Branches execution with if/else or switch logic based on any value in the workflow state.
  </Card>

  <Card title="Stop If" icon="octagon-xmark">
    Ends the workflow immediately when a condition is true. Use this to short-circuit on invalid input or terminal errors.
  </Card>

  <Card title="Continue If" icon="circle-check">
    Proceeds only when a condition is met; otherwise skips the remaining blocks in that branch.
  </Card>

  <Card title="Delay" icon="clock">
    Adds a time-based pause between blocks. Useful for rate-limited APIs or workflows that need to wait for an external process.
  </Card>

  <Card title="Reduce" icon="list">
    Iterates over a list and aggregates results. Use this to process arrays of items — records, tickets, leads — in a single workflow run.
  </Card>
</CardGroup>

### Data and Integration Blocks

<CardGroup cols={2}>
  <Card title="Query Database Table" icon="database">
    Retrieves documents from a Scout Database — your internal knowledge base or stored workflow outputs.
  </Card>

  <Card title="Slack" icon="slack">
    Sends a message or creates a thread in any Slack channel or DM. Handles authentication and formatting for you.
  </Card>

  <Card title="Discord" icon="discord">
    Posts messages to Discord channels or direct messages without managing webhooks manually.
  </Card>

  <Card title="Twilio" icon="mobile">
    Sends SMS messages or initiates calls via Twilio. Handles credentials and request signing automatically.
  </Card>
</CardGroup>

## Choosing the Right Block

Use this reference table to select the right block for each step in your workflow.

| Situation                           | Block to use           |
| ----------------------------------- | ---------------------- |
| Accepting caller input              | Input                  |
| Generating or analyzing text        | LLM or Reasoning       |
| Calling a REST API                  | HTTP                   |
| Branching on a value                | Condition              |
| Stopping on an invalid state        | Stop If                |
| Custom deterministic logic          | JavaScript             |
| Storing results for later retrieval | Save Document to Table |
| Sending a Slack message             | Slack                  |
| Sending an SMS                      | Twilio                 |
| Iterating over a list               | Reduce                 |

**LLM vs. JavaScript** — Use JavaScript when the logic is deterministic and testable with unit cases. Use LLM when the input is unstructured, ambiguous, or requires language understanding.

**HTTP vs. integration blocks** — Integration blocks (Slack, Twilio, CRM) handle authentication and request formatting for you. Use HTTP for any other API.

**Condition vs. Stop If** — Stop If ends the workflow immediately. Condition routes execution to different downstream branches and keeps the workflow running.

## Agent Blocks: Embedding AI Judgment

An Agent Block lets you run a fully configured Scout agent as a single step in your workflow. This is the mechanism that allows you to combine the reliability of structured automation with the adaptability of AI.

Use an Agent Block when:

* A step requires reading and interpreting unstructured text
* The right action depends on nuance that a simple condition can't express
* You want to reuse an existing agent's capabilities inside a larger process

Here is an example of an Agent Block configuration for a support ticket triage workflow:

```yaml theme={null}
block: agent
id: triage_agent
agent_id: "support_triage_v2"
inputs:
  ticket_subject: "{{ inputs.subject }}"
  ticket_body: "{{ inputs.body }}"
  customer_tier: "{{ fetch_customer.output.tier }}"
output_key: triage_result
```

The block passes the relevant ticket fields to the agent. The agent responds with a structured decision — for example, `{ urgency: "high", queue: "engineering", draft_reply: "..." }` — which downstream Condition and Action blocks can act on immediately.

<Tip>
  Keep Agent Block inputs small and explicit. Pass only the fields the agent needs to make its decision — not the entire workflow state.
</Tip>

## Condition Blocks: Branching Logic

A Condition Block evaluates an expression and routes execution to one of two or more downstream branches. Use it to handle different cases — different customer tiers, different ticket types, different API response codes — without duplicating the rest of your workflow.

```yaml theme={null}
block: condition
id: route_by_urgency
condition: "{{ triage_agent.output.urgency }}"
branches:
  high:
    next: escalate_to_engineering
  medium:
    next: assign_to_senior_support
  low:
    next: send_auto_reply
```

You can chain Condition blocks to handle complex routing trees. Keep each condition focused on a single decision to make the workflow readable.

## Transform Blocks: Reshaping Data

Transform blocks (Text, JSON, and JavaScript blocks) restructure data between steps. Use them to:

* Extract a specific field from a large API response
* Rename keys to match a downstream block's expected schema
* Combine values from multiple prior blocks into a single object
* Format a date, truncate a string, or compute a derived value

Here is a JavaScript Transform block that extracts and normalizes fields from a raw webhook payload:

```javascript theme={null}
// Block ID: normalize_payload
const raw = inputs.webhook_body;

return {
  ticket_id: raw.id,
  subject: raw.fields?.subject ?? "No subject",
  body: raw.fields?.description ?? "",
  customer_email: raw.reporter?.email?.toLowerCase(),
  created_at: new Date(raw.created).toISOString(),
};
```

Downstream blocks reference the normalized fields as `{{ normalize_payload.output.ticket_id }}`, `{{ normalize_payload.output.subject }}`, and so on.

## Block Design Rules

Follow these rules to keep your workflows maintainable as they grow:

* **One responsibility per block.** A block that fetches data should not also transform it. Split the jobs.
* **Name blocks by what they do.** `classify_urgency` and `fetch_customer` are far more useful than `llm_1` and `http_2` when reading logs.
* **Guard expensive or irreversible actions.** Place a Condition or Stop If block before any write operation, external API call with side effects, or message send.
* **Keep transformation chains explicit.** Avoid long implicit data reshaping inside a prompt. Use a Transform block first so the LLM receives clean, predictable input.

## Next Steps

<CardGroup cols={2}>
  <Card title="Creating Workflows" icon="hammer" href="/workflows/creating-workflows">
    Apply the validate-fetch-decide-act-return pattern when assembling your blocks.
  </Card>

  <Card title="Running Workflows" icon="play" href="/workflows/running-workflows">
    Execute your workflow and inspect block-level output in the Console.
  </Card>

  <Card title="Logs" icon="magnifying-glass" href="/workflows/logs">
    Trace block-by-block execution and debug failures in production.
  </Card>

  <Card title="Environments" icon="layer-group" href="/workflows/environments">
    Promote your workflow safely from development to production.
  </Card>
</CardGroup>