Back to Sim

Overview

apps/docs/content/docs/en/connections/index.mdx

1.0.03.7 KB
Original Source

import { Callout } from 'fumadocs-ui/components/callout' import { Card, Cards } from 'fumadocs-ui/components/card' import { ConnectIcon } from '@/components/icons' import { Video } from '@/components/ui/video' import { FAQ } from '@/components/ui/faq'

Connections are the pathways that allow data to flow between blocks in your workflow. They define how information is passed from one block to another, enabling you to create sophisticated, multi-step processes.

<Callout type="info"> Properly configured connections are essential for creating effective workflows. They determine how data moves through your system and how blocks interact with each other. </Callout> <div className="mx-auto w-full overflow-hidden rounded-lg"> <Video src="connections.mp4" /> </div>

Connection Types

Sim supports different types of connections that enable various workflow patterns:

<Cards> <Card title="Connection Basics" href="/connections/basics"> Learn how connections work and how to create them in your workflows </Card> <Card title="Connection Tags" href="/connections/tags"> Understand how to use connection tags to reference data between blocks </Card> <Card title="Data Structure" href="/connections/data-structure"> Explore the output data structures of different block types </Card> <Card title="Accessing Data" href="/connections/accessing-data"> Learn techniques for accessing and manipulating connected data </Card> <Card title="Best Practices" href="/connections/best-practices"> Follow recommended patterns for effective connection management </Card> </Cards>

<FAQ items={[ { question: "How does data actually flow between connected blocks?", answer: "The execution engine builds a directed acyclic graph (DAG) from your connections and processes blocks in dependency order. When a block finishes, its output is stored in the execution context. Downstream blocks reference that output using connection tags like <BlockName.response>, which the variable resolver replaces with the actual data at execution time." }, { question: "Can a block receive input from multiple upstream blocks?", answer: "Yes. A block waits until all of its incoming connections have been fulfilled before it executes. The engine tracks incoming edges for each node and only marks a block as ready when every upstream dependency has completed. You can reference outputs from any connected block using their respective connection tags." }, { question: "What happens if an upstream block fails?", answer: "If a block errors, the engine activates the error edge (if one exists) and deactivates the normal output edge. Downstream blocks on the success path will not execute. You can connect an error handle to a separate block to build fallback or recovery logic." }, { question: "Do connections support conditional branching?", answer: "Yes. Router and Condition blocks produce a selected route or option that determines which outgoing edge is activated. Only the blocks on the chosen path will execute. Edges on unselected paths are deactivated and their entire downstream subgraph is skipped." }, { question: "Can blocks in parallel branches share data with each other?", answer: "Blocks within the same parallel branch cannot directly reference blocks in a sibling branch because branches execute independently. However, once all branches complete and the parallel block exits, downstream blocks can access the aggregated results from all branches." }, { question: "How are connection tags formatted?", answer: "Connection tags use angle-bracket syntax: <BlockName.property>. For nested data you can chain dot notation, such as <BlockName.response.items[0].name>. The resolver walks the object path at execution time and substitutes the resolved value into your input field." }, ]} />