Workflows

A visual builder for multi-step AI automations: connect triggers, AI steps, logic and actions on a canvas, version them, and run them.

In Kasimir, Workflows are multi-step, form-based automations that you assemble on a visual canvas. A workflow always begins with a trigger (what starts it) and then runs a chain of nodes — AI steps, logic branches, and actions such as sending email or generating a document. Unlike a chat, a workflow runs reproducibly according to fixed rules, can be versioned, and can also start automatically (on a schedule, via a webhook, or from a public form).

This page describes the workflow editor, every node type, publishing (deploy), and running — exactly as the product behaves.

Overview: where workflows live

• List: /workflows (and the Workflows tab in the Library) shows your existing workflows as cards plus a row of templates you can clone.

• Editor: /workflows/<id>/edit — the canvas where you build.

• Run: /workflows/<id>/run — the input form and the live run view.

• History / Executions: /workflows/<id>/runs — the table of past runs.

Inside the editor, the top tab bar switches between Editor and Executions.

Creating a workflow

1. Open /workflows and click + Neuer Workflow (New workflow). An empty workflow named "Neuer Workflow" is created and the editor opens.

2. Alternatively, click a template under Vorlagen — it is copied into your company, auto-arranged tidily, and opened in the editor.

3. In the empty editor, the trigger picker appears first. Choose what starts the workflow (see below). Only then can you add further nodes.

The editor

The editor has four areas:

• Top bar (left): back arrow, emoji + name (clicking opens a menu with Rename, Pin, Export/Import as JSON), the tab bar, and the save indicator (Saved / Unsaved / Saving…).

• Top bar (right): Save, the Active toggle, the gear for Workflow settings, the Run link, and the Publish (deploy) button.

• Canvas (center): the nodes and their connections. Drag nodes freely; create connections by dragging from port to port.

• Floating toolbar (bottom): add node, settings, history, Tidy up (auto-layout), and undo/redo.

Working on the canvas

• Add a node: via the bottom toolbar, or via the + on an existing connection (the new node is then inserted directly into that edge). The node picker opens with a search box and the category filters Logic, AI, Actions. Typing filters; ↑/↓ move the highlight; Enter adds it.

• Select a node: clicking opens the right-hand settings panel (resizable; the width is remembered).

• Node menu (⋯): rename (changes the technical slug), duplicate, Disable node (pass-through), replace, delete, add note, and Test up to here.

• Undo/redo: Cmd/Ctrl+Z and +Shift. (Inside text fields the browser's native undo applies.)

• Tidy up: automatically arranges the nodes for clarity.

• Export/Import: from the name menu you can save the workflow as JSON and load it back (import overwrites the current nodes and edges — with a confirmation).

Triggers — how a workflow starts

The trigger is the first node. There are five modes:

Input variables

On the trigger you define the workflow's input variables. Each variable has:

• a technical key (lowercase a–z, digits, _, up to 40 chars),

• a display label, optionally a placeholder,

• a type: text, longtext (multi-line), select (with an option list), or boolean (checkbox),

• a required flag and an optional default value.

These values are available to downstream nodes as {{trigger.input.<key>}}. For a webhook you map incoming JSON fields to these keys via JSONPath (e.g. $.email); the Outlook-mail trigger exposes a fixed set of variables (from, subject, to, cc, body, received_at, message_id, attachments).

Referencing variables

Anywhere a field is called a "template", you can insert values from previous steps:

• {{trigger.input.<key>}} — a trigger input value.

• {{<slug>.output}} — the full output of a node (the slug is the node's technical name).

• {{<slug>.output.<path>}} — a nested field, e.g. {{research.output.rows}}.

• Inside a loop: {{<loop-slug>.output.item}} for the current element and .index for the counter.

Node types

The node picker groups all steps into three categories.

AI

• LLM — the core AI step. Options: Model (or the workflow default model), System prompt, User prompt template, Temperature, attached Knowledge (company documents), Tools for an agentic mode (e.g. web_search, fetch_page — then the node runs as a reasoning loop with a max-steps cap of 1–25, default 6), Memory (session key + window size for conversation history), Structured output (JSON schema), and optionally an existing Assistant that supplies persona, model, and tools.

• Ask user (ask_user) — pauses the run and shows a form; the answers flow on like a second trigger.

• Check (check) — AI-based content checks (moderation, pii, jailbreak) with a passed/flags/reason verdict. Relevant for GDPR.

• Image generation (image_gen) — produces 1–4 images from a prompt at 1024×1024, 1024×1792, or 1792×1024 (requires an image model).

Logic

• Condition (if_else) — one or more conditions combined with all (AND) or any (OR); two outputs (true/false).

• Router — several named routes. Make.com semantics: all matching routes run (sequentially). A route with no condition always runs; a "fallback" route runs only when none other matched.

• Loop (for_each) — iterates over an array; per element {{slug.output.item}} is available. Optional iteration cap.

• Aggregate (aggregate) — collects one value per iteration and emits it as an array or as joined text (with a separator); optional de-duplication.

• Delay (delay) — pauses for a fixed duration (seconds/minutes/hours/days).

• Code (code) — runs Python; predecessor outputs are available as an inputs dict, results via print() (JSON is taken as structured output). Requires the Python sandbox to be enabled.

Actions

• Load table (load_table) — reads an attached XLSX/CSV file as row objects (rows, count, columns); ideal as a loop source.

• Create document (doc_render) — generates a real file as docx, xlsx, pdf, or pptx, either from Markdown or from an uploaded template.

• Save to storage (save_to_storage) — writes content persistently as a file (inline mode from text, or forward from a doc_render node).

• Send email (send_email) — sends an email (Markdown → HTML) via SendGrid to interpolated recipients.

• Post message (post_message) — to slack, teams, or a webhook.

• HTTP request (http_out) — calls an external API (method, headers, query params, body modes, bearer/basic auth, timeout).

• Web search (web_search) — searches the web (up to 10 results).

• Document search (doc_search) — RAG search across company-wide or project documents (up to 20 results).

• Output (output) — marks a named final result.

• Notification (notify) — writes a message to the initiator's inbox.

• Microsoft 365: Outlook draft, Outlook send, Outlook event, OneDrive upload, Teams card.

• Google Workspace: Google Drive upload, Google Calendar event, append a Google Sheets row.

Per-node options

Every node also offers, via the ⋯ menu and the settings panel:

• Name & note: a readable title (the slug stays the technical reference) and a note on the node.

• Disable: the node is skipped and passes its input through.

• Error handling: stop (default — the whole run fails) or continue (the node is marked failed but the run proceeds; downstream output is empty).

• Retries: 0–5 re-attempts before error handling is applied.

• Human approval: pauses the run before this node and waits for approval.

• AI fields: let the model fill individual fields automatically (auto or via prompt).

Validation, saving, publishing

While you build, the editor validates continuously:

• Nodes with configuration errors get a red badge; an error box at the bottom-left lists graph problems and the count of faulty nodes.

• Save persists your changes. While errors exist you cannot save or publish cleanly.

A workflow does not run from saving alone. It must be published (deployed):

1. Click Publish. The panel shows the next version (semver) and a change diff (added + / changed ~ / removed − for nodes, edges, trigger).

2. Choose the version bump patch / minor / major.

3. Enter a description (required).

4. Publish. Earlier versions can be restored from the same panel.

The Active toggle controls whether the workflow may start at all. A workflow that is unpublished or disabled cannot run — the run page points this out.

Running

Open Run (/workflows/<id>/run):

1. Fill in the Inputs form (the trigger variables). Required fields are marked with *; missing ones are flagged before start.

2. Click ▶ Run.

The run view shows:

• a status banner: running, waiting for your input, waiting for approval, completed, failed, or cancelled, plus progress x / y steps.

• on an approval pause, a card with Approve / Reject.

• on an ask-user step, a form with Continue.

• a result card with ↓ Download file when a step produced a file.

• a step-by-step list with live output per node.

• an expandable Technical overview (diagram) of the canvas with live status.

Restart resets the view; History leads to past runs.

History / Executions

At /workflows/<id>/runs (the Executions tab) you find a table of all runs with Date, Trigger, Status, and Duration. You can filter by trigger type and reload with Refresh. Clicking a row opens the run detail.

Workflow settings

The gear opens Workflow settings:

• Icon (emoji) and Name

• Description

• Default model — the model LLM nodes use when they have no model of their own

• Project scope — Company-wide or assigned to a project

• Pin to sidebar (Admin/Owner only)

Limits of the current version