Starting a Workflow
Every run of a workflow begins at its Start node, and most workflows need some information to work with: a customer’s name, a policy number, an uploaded document. This page explains how to describe what a run needs, so the right information is there before any step runs.
Describing the information a run needs
On the Start node you can define an input schema: a short list of the fields a
run expects. For each field you give a name and a type (text, number, and so
on), and you mark which ones are required. For example, a quote-intake workflow
might require a customer_name and an email, and accept an optional
priority number.
Defining these fields has two benefits:
- Runs are checked before they begin. If someone starts the workflow without a required field, or sends a number where text was expected, the run is turned away with a clear message instead of failing partway through.
- The shape is documented. Anyone starting the workflow can see exactly what to provide.
Defining an input schema is optional. A workflow with no schema accepts any information, or none at all.
Whatever a run is given becomes available to your steps as values on the Start
node, so later steps can read customer_name, email, and the rest. See
Variables & Data Flow.
Attaching files
A run can also start with files attached, such as a PDF application or a CSV of contacts. Uploaded files are stored securely and made available to steps that work with them, like the Agent, which can read a document and answer questions about it.
A few limits apply to file uploads:
Ways to start a run
A workflow can begin in more than one way:
- Manually, by starting it yourself to try it out or run a one-off.
- On a request from another system, using a webhook. See Triggers & Webhooks.
- On a schedule, so it runs automatically at set times.
However a run starts, the same input schema and file rules apply, so the information reaching your steps is consistent.