Build Powerful Workflows with Vellum Nodes — Vellum

Supported Nodes

Vellum offers over a dozen Node types that you can use to build any Workflow you can imagine. On this page, we’ll outline the purpose of each Node.

For additional examples of Node usage, check out our Common Workflow Architectures, which we update regularly.

Quick Reference

Node	Description
Prompt Node	Invoke LLMs with your prompts, optionally using variables from other nodes
Templating Node	Apply Jinja templating to perform lightweight data transformations
Search Node	Search against a Document Index, great for RAG
API Node	Make an HTTP request to an API endpoint
Code Execution Node	Run custom Python or Typescript code
Subworkflow Node	Makes Workflows reusable and more maintanable as they get more complex
Map Node	Iterate over an array, executing a sub-workflow for each item
Guardrail Node	Run an inline evaluation using a pre-defined Metric
Conditional Node	Branch your workflow based on a condition, also useful for error handling
Merge Node	Wait for one or multiple branches to complete before continuing
Final Output Node	Exposes values you can use in your application, you may have more than one!
Error Node	Stop workflow execution and raise an error
Note Node	A simple node that displays text to help annotate your Workflow

Prompt Nodes

A core part of any LLM application. This node represents a call to a Large Language Model. Similar to Vellum Prompts, you can use models from any of the major providers or open source community, including: OpenAI, Anthropic, Meta, Cohere, Google, Mosaic, and Falcon-40b.

Upon creating a Prompt Node you’ll be asked to import a prompt from an existing Deployment, Sandbox, or create one from scratch. Prompts are defined by their variables, prompt template, model provider, and parameters. Refer to this help center article to learn more about our prompt syntax (Vellum Prompt Template Syntax).

Templating Nodes

The Templating Node allows you to perform custom data transformations on a set of defined inputs to create a new output. You can use this to define constants, manipulate data before feeding into a prompt, or massage a response to a format of your liking.

Check out our Common Data Transformation Templates for some common examples.

Tip: JSON Syntax

Tip: Unexpected Whitespace

Search Node

The Search Node returns results from a Document Index stored inside Vellum Search. Once your documents are uploaded in an index (details on how to do that here: Uploading Documents), you can start using them in a Workflow.

The index in a Search Node can be fixed for the Workflow or chosen dynamically based on the output of an upstream node. Additional configuration options, similar to the ones in Vellum Search are also available in the Search Node.

API Node

The API Node invokes an API endpoint and returns back the status code, raw output, and JSON output if applicable. These APIs can be either publicly accessible or privately defined within your backend through the help of Authorization headers and Secrets. Simply define a URL, HTTP Method, relevant additional headers, and the body that you would like to send to the desired endpoint.

Tip: Creating Dynamic URLs

Code Execution Nodes

The Code Execution Node empowers you to include custom logic defined directly in the workflow. You can even import custom public packages within the node’s logic. We support the following languages:

Python
TypeScript

Tip: Outputting Arrays (Strings)

Tip: Outputting Arrays (Function Calls)

Subworkflow Nodes

Subworkflow Nodes are essential for managing giant, complex workflows. Define reusable groups of nodes in one Workflow Sandbox and have them directly accessible upon deployment from any other workflow in your workspace. Subworkflow nodes also support release tag specification, allowing you the option to always invoke the latest workflow, or pinning to a specific release tag defined by you.

Check out the video below to see Subworkflow Nodes in action!

Inline Subworkflow Nodes

Subworkflow Nodes could also be defined directly within the existing Workflow editor! This spawns a new editor within the existing parent Workflow that supports many of the same features as the parent Workflow such as all existing nodes and copy/paste. This could be used to help organize complex Workflow architectures into separate, digestable groups. Check out the video below to see it in action!

Map Nodes

Map Nodes allow you to easily run the same Subworkflow multiple times in a row or in parallel, with up to 96 concurrent executions.

Map Nodes take a JSON array as an input and run the same Subworkflow for each item in the array. The Subworkflow is provided with three input variables on each iteration: item (the value in the current iteration of the array), items (the entire array), and index (the position of the current iteration, as a number). The output of every Subworkflow is then combined into a single value as the output of the Map Node, with the special Vellum type ARRAY (not JSON).

Tip: Quirks with Map Node Input Types

Guardrail Nodes

Guardrail Nodes allow you to use Evaluation Metrics from within a Workflow. Guardrail Nodes let you run pre-defined evaluation criteria at runtime as part of a Workflow execution so that you can drive downstream behavior based on that Metric’s score.

For example, if building a RAG application, you might determine whether the generated response passes some threshold for Ragas Faithfulness and if not, loop around to try again.

Conditional Node

Conditional Nodes are extremely powerful because they can help you diverge the execution path of your Workflow based on the results of an upstream node. The Conditional Node supports as many if-else-if conditions as you’d like and the rules can be grouped / nested within each other.

The number of exit options from a conditional node equal the number of if-else-if conditions created on the node

Tip - Equality Checking Templating Nodes

See our tips about invisible whitespace in Jinja

Wrong Way To Check Equality From Templating Nodes

The issue in the above check is that we’re not using the Jinja2 syntax to remove unintentional whitespace: {%- and {{- rather than {% or {{

Right Way To Check Equality From Templating Nodes

You can see here that adding the - character fixes the issue and gets the correct branch to execute after the conditional.

Merge Node

Merge Nodes are used when the goal is to bring back the execution of divergent paths into one path. You can configure the number of inputs to a Merge Node and choose between “Await All” or “Await Any” as your merge strategy. The merge strategy determines the logic that will continue workflow execution.

Final Output Node

The Final Output Node represents the end of your workflow. Your workflow may have multiple Final Output Nodes if the execution has been branched off from an upstream node.

A name for the output and an output type must be configured here because the response streamed back from the endpoint (when the workflow is taken to production) has this information included.

Error Node

The Error Node enables you to reject the full workflow, terminating execution with an error event wherever you define it in your execution flow. There are two types of errors you could raise with this node:

Pass-through - Use an Error output from an upstream node and pass it through to this node.
Custom - Define your own String output that this node will use as an error message

Note Node

The Note Node helps you keep your workflow organized and maintainable. You can use it to add context, related links, or other pieces of information in your workflow. They don’t alter any functionality in your workflow, and are purely for your team and you. You can change the font size and even use colors!