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: The Workflows entry in the sidebar opens the Library on the Workflows tab, which shows your workflows as cards. Templates to copy are in the Templates tab.

• 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. In the library’s Workflows tab, click + New Workflow. In the Create a new workflow dialog, enter a Workflow name; optionally add a Description, tick Save as template and choose the Initial trigger type (default: Manual). Create workflow opens the editor.

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

3. The new workflow already starts with a trigger of the chosen type; you can change the mode on the trigger at any time. The trigger picker only appears when a workflow has no nodes at all.

Sharing and permissions

Use Share in the editor to set visibility and shares:

• Visibility: Private (default) or Whole company – everyone sees and runs company-wide workflows.

• Shares to a person, a team or a project with the role View, Run or Edit. A team reaches all members, a project its members and its home team. For a company-wide workflow only Edit can be granted – everyone may see and run it anyway.

• Visibility and shares can be changed by the creator and – for company-wide workflows – by owners and admins; only they see Share. Someone who only holds a share cannot pass it on. Sharing with individual people needs no further permission; shares with teams and projects as well as “Whole company” also require the “Share workflows” permission (admins only by default).

• You can also add shares to a team or project in the Workflows tab of the team or project view (Add workflow) and remove them there with Remove from here. In the library, a pill on the workflow shows which team or project it is assigned to.

Owners and admins see other people’s private workflows under Administration → Workflows only as structure (name, cost, limits, disable, delete) – they cannot open or run them.

The editor

The editor has five areas:

• Top bar (left): back arrow (to the library), emoji + name (clicking opens a menu with Rename, Pin, Export/Import as JSON), the tab bar, and the autosave indicator (Saved, Saving soon…, Saving… or Unsaved — fix errors; without edit rights View only).

• Top bar (right): the On/Off toggle, the gear for Workflow settings, Share, the Run link, the note Draft — test runs use this state · Live: revision n, and the Deploy button (creator, owners and admins only).

• 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.

• AI assistant (left edge): the AI assistant tab (“KI-Assistent”) opens a chat in which you build and change the workflow. It works directly on the canvas; your own changes are kept.

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.

• Loops: a loop sits in a violet frame; its body steps carry a ↻ and are connected by dashed lines. The violet + inserts at the end of the body and only offers blocks allowed there. Drag steps into or out of the frame; a new loop comes with its Aggregate node.

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

• Node menu (⋯): Test up to here, Test from here (with the last run's data) (once there is an earlier run), add comment, rename (changes the technical slug), Disable node (pass-through), replace node, duplicate, clear output, and delete.

• 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: short text, text block, email, phone, URL, number, select (dropdown), single choice, multiple choice, on/off, hidden field, legal text/consent, file or knowledge source,

• a required flag and optionally a 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.

Building blocks

The block picker groups all steps into AI, logic and actions. What each block does and what to keep in mind when setting it up is described under Workflow building blocks.

Limits can be set for the AI step’s tools: allowed and blocked websites and the number of searches for web search, allowed websites and up to five mandatory sources for reading pages (read before the run), and fixed sources and the number of hits for document search. Your company’s source policy applies on top.

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. Under “Benachrichtigen (Freigeber)” (notify approver) you choose who is notified via inbox and push; if left empty, it is the person starting the run.

• AI fields: let the model fill individual fields automatically (auto or via prompt). This is not possible for recipients and targets (e.g. email recipient, HTTP URL). If a recipient or target comes from AI, file or search results – for automatic runs also from form or webhook inputs –, saving requires “Human approval” on this node.

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.

• The editor saves automatically. While errors exist, autosave pauses and you cannot publish.

A workflow does not run from saving alone – saving keeps the draft, which test runs use. For every other start it must be published (deployed):

1. Click Deploy. 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 On/Off toggle controls whether the workflow may start at all. A workflow that is unpublished or switched off 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. If results go to fixed targets (e.g. email recipients) or a named person sees them during an approval, this is shown above the button. If excerpts from sources that are not company-wide go to such targets, you confirm this with a checkbox.

2. Click ▶ Run.

The run view shows:

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

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

• while waiting for the knowledge index, the progress per source and Start now with partial content.

• for Fill form, the review card (“Formular prüfen”) with the draft; completing the review creates the final version.

• 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 runs with Date, Trigger, Status, and Duration. You can filter by trigger type and reload with Refresh. Clicking a row opens the run detail. Members only see runs they started themselves – so not runs from a schedule, webhook, form or integration. Owners and admins see all runs; other people’s manual runs only with status, time and cost, without being able to open them.

The Cost column shows the AI cost per run; the run detail shows the cost of this run and the cost per node.

Workflow settings

The gear opens Workflow settings:

• Icon (emoji) and name

• Description

• Default model – the model AI steps use when they have no model of their own

• Project (knowledge search) – assigns the workflow to a project; its document search then includes project documents

• Pin to sidebar (for everyone: owners and admins only)

• Cost & limits – monthly limit, limit per run and runs per hour (see workflow settings in administration)

• Automatic runs – whether runs without a starting person (schedule, form, webhook) may use company knowledge and the creator’s personal connections; confirmed by owners or admins

Limits of the current version