Workflows

A workflow is an automation that runs from start to finish on its own, with a clearly defined sequence of steps. This page covers everything you can do inside the workflow editor that does not apply to agents.

For the shared concepts (triggers, steps, memory, conditions), see Core Concepts. For the type-specific page on agents, see Agents.

When to build a workflow (and not an agent)

Build a workflow when:

• The automation should run without a user present — on a schedule, on an event, on a webhook.
• The sequence of actions is predictable — you know step 1, step 2, step 3.
• You want clear inputs and outputs — trigger data in, side effect out (email sent, file written, ticket updated).

Build an agent instead when the interaction is open-ended, the user drives the flow, and the order of actions depends on the conversation. See Agents.

The editor

When you open a workflow from the Automations tab, the editor appears with three main areas:

• Toolbar — at the top: name, description, and the action buttons Jobs, Manual Run, Duplicate, Export, Remove, Save.
• Trigger — the single trigger configured for this workflow.
• Steps — a vertical list of tasks, in execution order.

Adding the trigger

A new workflow starts without a trigger. Pick from the list of available trigger integrations — the full catalog is documented under Integrations.

After selecting the trigger you configure its fields right there. Triggers usually need:

• The timing or source (cron expression, webhook secret, mail folder, …).
• One or more output names — where in memory the trigger should drop the data it received.

Every workflow has exactly one trigger. To change the trigger, replace it — the steps remain.

Adding steps

To add a task, type the integration name into the integration input field below the last step. The field auto-completes against the catalog of available integrations. Pick the one you want, and the step appears below.

Step fields generally come in three flavors:

• Plain inputs — you type a value or pick from a list.
• Memory inputs — you point to a name already in memory. The step reads that value at runtime.
• Memory outputs — you name a memory key. The step writes its result there.

A few fields have special behavior — these are noted on each integration's page:

• Model fields — pick from the workspace's configured models.
• Knowledge fields — pick from the workspace's configured knowledge bases.
• Persona fields — pick from the workspace's configured personas.
• Secured fields — credentials, API keys, passwords. The platform stores these encrypted and never shows them again after you save.
• OAuth fields — for integrations like Google Calendar; the platform takes you through the connection flow.

Reordering and removing

• Drag a step by its handle to reorder.
• Click the trash icon on a step to remove it. Memory written by that step disappears with it — make sure no later step still depends on it.

Conditions on steps

To make a step conditional, click Add condition. Pick deterministic for a logic formula or natural language for a sentence the AI judges. See Core Concepts → Conditions.

Interactive steps

You can insert an interactive step anywhere in a workflow. It pauses the run and asks a user a question (free-form text, choices, file upload). The conversation shows up in the Inbox. Once the user answers, the workflow resumes from the next step with the answer in memory.

Use interactive steps sparingly — every one of them is a hand-off that blocks the automation until someone responds.

Manual Run

The Manual Run button takes you to a dedicated page where you provide the data that the trigger would normally supply (or no data at all, for time-based triggers), and start the workflow immediately.

Use Manual Run for:

• Testing while building.
• Re-running a single failed input.
• One-off operations that would otherwise need a real trigger.

Jobs — past runs

Every run of a workflow produces a job. The Jobs view (reachable via the Jobs button in the toolbar) lists them, newest first, with:

• A status — running, completed, failed, waiting (paused on a user input).
• Start and end time, duration.
• The trigger that fired it.

Click a job to open the job details: a chronological log of everything the run did — every step that started, every model call, every retrieval, every error. The log entries are emoji-tagged (📩 for incoming messages, 🤖 for agent turns, 📊 for metrics, 🔍 for retrieval queries, …) so you can scan large runs quickly. This is your debugging tool when something goes wrong.

Activating and deactivating

Triggers are started and stopped from the Trigger Monitor under Administration, not from the editor. The editor only stores the configuration; the Trigger Monitor decides whether that configuration is currently listening.

• Running — the trigger is armed (or, for cron, scheduled). The workflow will run when the trigger fires.
• Stopped — the workflow exists but will not run automatically. Manual Run still works.

This split lets non-Admin editors build and test workflows without ever having permission to put them live — that decision sits with an Admin in the Trigger Monitor.

Exporting and importing

The Export button on the editor's toolbar downloads the entire workflow as a YAML file — every step, every configuration, every condition. The file does not contain secured values (credentials) — those stay in the workspace they were created in.

The Import button on the Automations list takes a YAML file and creates a new workflow from it. Models, knowledges, and personas are referenced by ID — the import succeeds even if those references don't exist yet, but the workflow won't run until you wire them up.

Use this to:

• Share workflows between workspaces.
• Back up an important workflow before making large changes.
• Bootstrap a new installation from a template library.

Other toolbar actions

• Duplicate — creates a copy of the workflow under a new name. Useful for variants or for editing a copy while the original keeps running.
• Remove — deletes the workflow. Existing jobs remain in the Jobs view but no new runs can be started.

Recommendations

• ✅ Keep the trigger stopped in the Trigger Monitor until Manual Run has succeeded with realistic input.
• ✅ Give memory keys descriptive names. customer_record is far easier to read than data1.
• ✅ Keep workflows short. If a workflow has more than ten or twelve steps, consider splitting it into two — one calls the other via a webhook.
• ✅ Check the Jobs view after a workflow has been running in production for a day. Quietly failing jobs are a common surprise.
• ⚠️ Reordering a step does not automatically check that the new neighbors are happy with the change. Re-run manually after reordering.
• ⚠️ Exported YAML files are human-readable but not stable across major platform versions. Re-export periodically if you keep backups.
• ❌ Do not use deterministic conditions for things that require judgement — they will be brittle. Use natural-language conditions instead.
• ❌ Do not put secured values directly into a workflow step's plain field. Always use a secured-field-type input.

What to do next

• Integrations → Introduction — catalog of all available triggers and actions.
• Administration → Trigger Monitor — start the trigger once the workflow is ready.
• Models → Introduction — connect the AI engines workflows depend on.
• Knowledge → Introduction — add your own data for the AI to search.
• Metrics → Consumption — see how much each workflow costs to run.