LLM Step

Description

The LLM Step runs a prompt against a large language model as one step in a workflow. You can give the model scoped, read-only access to specific tables, dimensions, and documents in your project, and you require it to return a structured JSON response that matches a schema you define. That structured response is then routed through one or more outputs — for example, generating one PDF per row of the response.

A common use is to summarize a financial table into per-business-unit commentary and write each commentary out as its own PDF in a document account.

Note

Scoped access to project data (tables, dimensions, documents) is available with Anthropic LLM connections, which use a secure connector to reach PlaidCloud’s read-only tools. Other providers can still run a prompt and return structured JSON, but they don’t get scoped data access — bindings are ignored for them.

Before You Start

You’ll need:

• An LLM connection. The step requires a connection of kind LLM (for example, Anthropic). The connection holds the provider API key and an optional default model. See Connections.
• A document account — only if you’re generating files. PDF output is written to a document account you choose.

Add an LLM Step

1. Open the workflow and go to the Analyze Steps tab.
2. Add a step in the position you want, the same way you’d add a standard transform.
3. Choose LLM Step as the step type. The editor opens with four sections: LLM Request, Bindings, Outputs, and Limits.

Configure the Request

In the LLM Request group:

• LLM Connection (required) — the LLM connection the step uses.
• Model (optional) — a specific model name, such as claude-opus-4-7. Leave it blank to use the connection’s default model.
• Prompt (required) — the instruction sent to the model. You can reference bound objects inline with {{tables.NAME}}, {{dimensions.NAME}}, and {{documents.NAME}}; each reference must match a binding you declare below.
• Result schema (required) — a JSON Schema the model’s output must conform to. It must be a JSON object with "type": "object" at the root. The step validates the response against this schema, so your outputs can rely on its shape.

Bind Project Data

The Bindings section grants the model read-only access to specific objects and tells it how to address them. It has three tables — Tables, Dimensions, and Documents — each with Add row and Remove selected buttons.

• Tables and Dimensions — Name (the label you reference in the prompt), Reference (the table or dimension ID), and Mode (read).
• Documents — Name, Account (document account ID), Path, Mode (read), and Format (such as pdf).

Note

The step is read-only. The model can query and read the objects you bind, but it cannot modify data, and it cannot reach objects you didn’t bind.

Define Outputs

The Outputs section routes the model’s structured response to a destination. At least one output is required. Each row has a Kind and a Config (JSON) value.

The available kind is pdf_per_item, which renders one PDF per element of an array in the response and uploads each to a document account. Its config fields are:

Field	Description
iterator	Name of the array field in the response to loop over — one PDF per element.
content_field	Per-item field holding the Markdown rendered into the PDF body.
title_field	Per-item field used as the PDF title (default title).
document_account	Document account ID to write to.
path_template	File path for each item, with {field} placeholders taken from the item. The date tokens {yyyy}, {yyyy-mm}, {yyyy-mm-dd}, and {yyyymmdd} are filled in automatically.
on_collision	error (default), skip, or overwrite when a file already exists at the target path.
account_root	Root path within the document account (default /).

For a response that returns a businesses array whose items each have business_name, title, and commentary, the config is:

{
  "iterator": "businesses",
  "title_field": "title",
  "content_field": "commentary",
  "document_account": "<document-account-id>",
  "path_template": "/pl-analysis/{yyyy-mm}/{business_name}.pdf",
  "on_collision": "overwrite"
}

Limits

The Limits group bounds the request:

• Max output tokens — the largest response the model may return (1,024 to 128,000; default 16,000).
• Credential TTL (seconds) — how long the step’s scoped, temporary data-access credential stays valid (60 to 3,600; default 1,800). The step’s job is bounded by this window, so set it long enough for the model to finish but no longer than necessary.

Run the Step

The LLM Step runs like any other step — as part of a full workflow run, or on its own (see Running one step in a workflow). When it runs, the step sends your prompt and scoped tool access to the model, validates the response against your result schema, and writes each output. The model call runs in its own job, so a long-running step doesn’t tie up the workflow runner.

Caution

Each run makes a real, billable call to your LLM provider and writes its outputs. When an output’s on_collision is error, re-running a step whose files already exist fails — use overwrite or skip for repeatable runs.