Workflows
Capture recurring AI tasks as reusable templates — with variables, steps, and a fixed output format.
A workflow is a saved prompt template with variables, optionally several steps, and a fixed output format. Instead of retyping the same prompt every Monday, you fill in the input fields and hit Run.
20 minutes of copy-paste prompting turn into 30 seconds of filling out a form — if the template is built cleanly. This page shows what cleanly built means.
Not sure which tool to use? Two comparison tables help you decide: Workflow vs. Assistant and Workflow vs. Prompt Library.
Capabilities
- Any number of steps, executed in sequence
- Variable types: short text, text block, dropdown, on/off
- Per-step model choice
- Per-step web search toggle (useful when only research steps need live information)
- Pinned reference documents (always attached) plus optional per-run file upload
- Output formats: Markdown in chat, Word/PDF/text, Excel/CSV, PowerPoint, structured JSON (for downstream processing in Make/n8n or your own APIs)
- Share with a project → colleagues run the workflow without editing it
PowerPoint and Excel as file output only work via workflows with the document output toggle enabled. You cannot generate a .pptx or .xlsx from a normal chat. If you need one, build a workflow.
What a good workflow looks like — three building blocks
Poorly built workflows produce decent results on the first test and quietly fail on the tenth run, because someone else fed them different inputs. A robust workflow makes three things explicit:
Write a job posting for the role {{position}} in the {{department}} team.
1Use {{position}}, {{department}}, and the uploaded requirement note.
2Match tone and structure of the pinned sample posting sample-job-posting.docx.
3Produce exactly these sections: Title, About us (3 sentences), Responsibilities (5-7 bullets), Profile (5-7 bullets), What we offer (4-5 bullets), Contact.
No closing summary. No emojis.
Senior Backend Engineer (m/f/d)
About us We build industrial software for mid-sized machine manufacturers. 40 people, profitable, remote-first with an office in Munich.
Responsibilities
- Evolve backend services in TypeScript/NestJS
- Design data models for order processing
- Run code reviews for 4 junior engineers
- ...
Profile
- 5+ years of backend experience with Node.js or similar
- ...
The workflow saves the result as .docx if document output is enabled — otherwise as Markdown in the chat. Subsequent steps can access this step's output.
Rule of thumb. A good workflow step names at least one variable, one reference, one output schema. Three building blocks — the run stays reproducible no matter who executes it.
Vague vs. precise — what happens without a schema
Same job-posting workflow, two variants:
"Write a job posting for {{position}}. Use the requirements from the uploaded document."
What happens across ten runs:
- Sometimes formal, sometimes informal tone
- Sometimes 3 bullets under Responsibilities, sometimes 12
- Sometimes emojis at the end, sometimes not
- HR has to rework every result. The workflow saves almost no time.
"Write a job posting for {{position}}, tone matching sample-job-posting.docx, with exactly these sections: Title, About us (3 sentences), Responsibilities (5-7 bullets), Profile (5-7 bullets), What we offer (4-5 bullets), Contact."
What happens across ten runs:
- Consistent structure and tone
- HR's edit is polish, not a rewrite
- 2 minutes per posting instead of 20.
Where the Workflow Wizard often trips
Output without a schema.
Symptom: Looks fine on the first test; a colleague gets a different format a week later and complains.
Cause: The prompt says what to produce but not in which shape. Models vary across runs in length, ordering, bullet style.
Fix: Spell out the output schema in the prompt as a list of sections or a sample table. If applicable, enable document output — .docx/.xlsx enforces a fixed structure.
Too many steps in a row. Symptom: Steps 1-3 are usable; from step 5 onward the topic drifts or variables from step 2 are ignored in step 6. Cause: Each step receives the output of the previous steps as context. Past 6+ steps the context grows long and the model loses the original task. Fix: Keep workflows to 3-4 steps max. If you need more: split into two workflows — the second takes the first's result as a file input.
Wrong granularity — either too specific or too generic. Symptom A: The workflow works only for one customer / one product — the second use case requires rebuilding it. Symptom B: The workflow is so generic that you end up retyping half the prompt on every run anyway. Cause: During design, the axis of variation was never decided. Should the workflow vary across roles? Across departments? Across tones? Fix: Before building, write down: "N people will run this workflow. What changes per run?" — that becomes the variable list. Everything else stays hard-coded in the prompt.
File upload without a format convention. Symptom: The requirement note is sometimes a PDF, sometimes an email, sometimes a whiteboard photo — results swing wildly. Cause: The prompt implicitly expects a specific input format but never says so. Fix: State explicitly in the prompt what the uploaded file contains and how it looks — e.g. "The uploaded document contains bullet points on the requirements, half a page to one page, English". If the format is unclear, disable file upload and use a text-block variable instead.
The trick — manual first, model second. Workflows don't replace an unclear process; they scale a clear one. Run the process manually in chat three times — with three different inputs — before saving it as a workflow. You'll notice which variables actually vary, where the prompt is too vague, and whether the model can deliver what you need at all. Jumping straight into workflow creation usually builds something that misses the real flow, and you only find out when colleagues start using it.