Start
The Start block is the default trigger for a workflow. It defines the inputs the workflow takes and runs it from three surfaces with the same shape: a manual run in the editor, an API deployment, and a chat deployment.
Input Format
Define the fields the workflow accepts. Each field has a name and a type — string, number, boolean, object, array, or files — and becomes available downstream as <start.fieldName>. A customerId field reads as <start.customerId>.
- Give a field a default value to prefill the manual-run form. Defaults are ignored on deployed runs.
- File fields accept uploads from both chat and API callers.
- Reorder fields to control how they appear in the editor form.
Outputs
The fields you define, plus conversation context when the workflow runs from chat:
| Output | What it is |
|---|---|
<start.fieldName> | Each Input Format field, by name |
<start.input> | The latest user message (chat only) |
<start.conversationId> | The active session id (chat only) |
<start.files> | Chat attachments (chat only) |
Per entry point
Run renders the Input Format as a form, prefilled with any default values, so you can retest without retyping. Submitting runs the workflow, and the values land on <start.fieldName>. File fields upload straight into <start.fieldName>.
The Input Format becomes the JSON request body. Each field is part of the body, and Sim coerces primitive types on the way in. File fields expect objects that reference uploaded files, so upload first, then invoke the workflow.
The Start block binds to the active conversation: the latest message fills <start.input>, the session id is <start.conversationId>, and attachments appear on <start.files>, alongside any Input Format fields. Extra structured context passed in at launch merges into the matching <start.fieldName> outputs.
Multiple triggers
A workflow can have more than one trigger. When you click Run in the editor, Sim runs the highest-priority one: the Start trigger first, then a Schedule, then external triggers (webhooks and integrations). So a workflow with both a Start and a Webhook runs from Start when you click Run. Running an external trigger by hand instead generates a mock payload from its expected shape, so downstream blocks can resolve their references while you test.
Best Practices
- Use Start as the single entry point when one workflow serves both API and chat callers.
- Prefer named fields over raw JSON. Typed Input Format fields are coerced automatically and read by name downstream.
- Validate early. Add a Condition right after Start when certain fields are required for the run to succeed.