Start
The unified entry point for manual runs, API calls, and deployed chat
Start is the default trigger for every new workflow -- it replaces what used to be three separate blocks (API, Manual, Input Form) with one unified entry point that handles all of them at once.
If you're looking at an existing workflow that still uses a separate API, Manual, or Input Form trigger block, that's fine -- those blocks still work. They're just no longer offered for new workflows in favor of Start. See API, Manual, and Input Form for those legacy blocks.
What It Handles
A single Start block is always ready to receive:
- Manual runs -- clicking Run in the editor
- API calls -- an authenticated
POSTto the workflow's execute endpoint - Deployed chat -- messages sent through a chat deployment
Every Start block always exposes three built-in fields regardless of how it was triggered: input (the primary text payload), conversationId (for chat continuity), and files. You don't need to configure anything to get these.
Adding Custom Fields
Beyond the three built-in fields, add your own typed fields in the Inputs section (the same Input Format builder used elsewhere in Mandala): string, number, boolean, object, array, or files. Each field becomes available downstream as <Start.fieldName>.
Using It
Only one Start-family trigger (Start, or a legacy API/Manual/Input Form block) is allowed per workflow. Schedule and Webhook triggers are the exception -- they can coexist with a Start-family trigger, or with each other, in the same workflow.
- Every new workflow already has a Start block by default -- there's usually nothing to add.
- Add custom Inputs if the workflow needs structured data beyond plain text.
- Connect the Start block's outputs to the rest of your workflow.
Best Practices
- Add custom Input fields when you need typed, validated data -- don't rely on parsing everything out of the plain
inputstring. - Pre-fill default values on Input fields so manual test runs in the editor don't require re-entering the same data every time.
- Remember that manual runs in the editor execute your draft canvas, not the deployed snapshot -- API calls, chat, and other public entry points use the deployed version. Redeploy after making changes you want those to see.