Start

The Start block is the default trigger for workflows built in Sim. It collects structured inputs and fans out to the rest of your graph for editor tests, API deployments, and chat experiences.

The Start block sits in the start slot when you create a workflow. Keep it there when you want the same entry point to serve editor runs, deploy-to-API requests, and chat sessions. Swap it with Webhook or Schedule triggers when you only need event-driven execution.

Fields exposed by Start

The Start block emits different data depending on the execution surface:

Input Format fields — Every field you add becomes available as <start.fieldName>. For example, a customerId field shows up as <start.customerId> in downstream blocks and templates.
Chat-only fields — When the workflow runs from the chat side panel or a deployed chat experience, Sim also provides <start.input> (latest user message), <start.conversationId> (active session id), and <start.files> (chat attachments).

Keep Input Format fields scoped to the names you expect to reference later—those values are the only structured fields shared across editor, API, and chat runs.

Configure the Input Format

Use the Input Format sub-block to define the schema that applies across execution modes:

Add a field for each value you want to collect.
Choose a type (string, number, boolean, object, array, or files). File fields accept uploads from chat and API callers.
Provide default values when you want the manual run modal to populate test data automatically. These defaults are ignored for deployed executions.
Reorder fields to control how they appear in the editor form.

Reference structured values downstream with expressions such as <start.customerId> depending on the block you connect.

How it behaves per entry point

When you click Run in the editor, the Start block renders the Input Format as a form. Default values make it easy to retest without retyping data. Submitting the form triggers the workflow immediately and the values become available on <start.fieldName> (for example <start.sampleField>).

File fields in the form upload directly into the corresponding <start.fieldName>; use those values to feed downstream tools or storage steps.

Deploying to API turns the Input Format into a JSON contract for clients. Each field becomes part of the request body, and Sim coerces primitive types on ingestion. File fields expect objects that reference uploaded files; use the execution file upload endpoint before invoking the workflow.

API callers can include additional optional properties. They are preserved inside <start.fieldName> outputs so you can experiment without redeploying immediately.

In chat deployments the Start block binds to the active conversation. The latest message fills <start.input>, the session identifier is available at <start.conversationId>, and user attachments appear on <start.files>, alongside any Input Format fields scoped as <start.fieldName>.

If you launch chat with additional structured context (for example from an embed), it merges into the corresponding <start.fieldName> outputs, keeping downstream blocks consistent with API and manual runs.

Referencing Start data downstream

Connect <start.fieldName> directly into agents, tools, or functions that expect structured payloads.
Use templating syntax like <start.sampleField> or <start.files[0].url> (chat only) in prompt fields.
Keep <start.conversationId> handy when you need to group outputs, update conversation history, or call back into the chat API.

Best practices

Treat the Start block as the single entry point when you want to support both API and chat callers.
Prefer named Input Format fields over parsing raw JSON in downstream nodes; type coercion happens automatically.
Add validation or routing immediately after Start if certain fields are required for your workflow to succeed.