Workflows

A workflow is a directed graph of tasks. You wire tasks together in the visual builder, declare what variables they pass to each other, publish a version, and from that point on the workflow runs the same way every time it is invoked.

Workflows live at /automation/workflows. Each workflow has a list view, a detail/builder page, and a code-defined Workflow Builder Genie that helps you author and debug it.

When we call workflows deterministic, we mean the graph, configuration, variable mappings, and published version are controlled. Individual AI Prompt or Agent tasks can still produce model-variable output, so use schemas, validation, and downstream task settings when an output must be constrained.

The Mental Model

Use workflows for the part of automation that should be visible, repeatable, and testable.

1

Caller

A trigger, user, parent workflow, batch, or agent invokes the workflow.

->

2

Inputs

Declared values like account_id, contact_id, stage_id, or prompt context enter the graph.

->

3

Tasks

Each step does one job: find records, enrich, run AI, branch, loop, update records, or call integrations.

->

4

Outputs

The workflow returns structured values to its caller or writes approved changes to GTM Engine.

If the work needs to happen the same way across many records, teams, or runs, it belongs in a workflow. If the work starts with a user's open-ended question, put that conversational layer in an agent and let the agent call the workflow as a tool.

Workflow Anatomy

Workflow Types

GTM Engine distinguishes a few flavors of workflow:

• Custom — built in your org for your use case.
• System — built-in workflows that power core features (enrichment, propensity scoring, AI auto-fill, etc.).
• Customized System — a copy of a system workflow that you've modified for your org.
• Tools — any workflow you've toggled "Use as Tool" on, which makes it available to agents.

The Automation Library Explore tab surfaces system workflows as installable cards grouped by category. One-click install copies the workflow into your org and opens the editor — and if the system workflow ships with default trigger templates, the install modal lets you review and edit those triggers (filter values, stage names, enums) before they're copied alongside the workflow.

The Builder

The workflow detail page is a multi-tab workspace:

• Workflow — the canvas itself: triggers, inputs, outputs, and the task graph.
• Diagnostics — schema, Liquid expression, variable reference, and AI output schema validation.
• Runs — recent execution history with per-step inputs, outputs, and errors.
• Version History — every published version, with the option to restore.
• Linked-resource tabs for nested workflows, agents, focused prompts, and schemas open as you click through them.

Versioning and Publishing

• Workflows have an explicit Publish action. Only the published version runs in production.
• After publishing, saving creates a new draft row (version + 1) so subsequent edits don't affect the running workflow until you publish again.
• GET /api/workflows/[id] returns the latest version by default; pass ?version=N to load a specific version.

This is why workflows are a good place to put operational rules. A published workflow gives you a stable version that triggers, agents, and users can call without being affected by draft edits.

Folders and Tags

Workflows organize into folders using folder: tags. The same pattern works for triggers and agents in the unified Automation Library, so a single tag can group everything related to a use case.

Task Types

A workflow is built out of tasks. The most commonly used ones include:

• AI Prompt (Text / Object / Image) — call an LLM with a prompt and structured inputs/outputs.
• Find Prospects — search the GTM Engine prospect graph and return accounts/contacts.
• Research Signal — run web research for a specific propensity signal and return reasoning + score.
• Enrich — call enrichment vendors for emails, phones, social data, job-change detection (Waterfall.io /v1/job/change), etc.
• Update Record — write structured values back to GTM Engine records.
• Instantly Sequence — add a contact to an Instantly campaign.
• Nested Workflow — run another workflow as a sub-step.
• For Each — iterate over an array (e.g. contact_ids from Find Prospects), run a nested workflow per item, return aggregate results. Supports sequential or parallel execution via concurrency, with a maxItems safety cap (default 500).
• Agent — invoke an agent as a step.

The auto-generated Task reference lists every task type with its inputs, outputs, and config.

Common Workflow Patterns

Triggers and the Input/Output Panel

Every workflow has a Triggers / Inputs / Outputs panel anchored to the top-left of the canvas:

• Triggers — which triggers invoke this workflow, with their per-trigger variable mappings.
• Inputs — the variables this workflow expects to be passed in. Set by callers (a trigger, a parent workflow, an agent invoking it as a tool, or a manual run).
• Outputs — the variables this workflow returns to its caller.

The panel is the workflow's public contract. If another team member, trigger, agent, or workflow calls it later, this is where they see what values must come in and what values come back out.

Workflow Builder Genie

The Workflow Builder Genie is a code-defined agent that lives inside the builder. It can:

• Read the current workflow, linked triggers, nested agents, AI models, and task capabilities.
• Validate schemas, Liquid expressions, variable references, and AI output schemas.
• Propose narrow patch operations against the workflow JSON instead of rewriting the whole thing.
• Create new workflows, triggers, and agents from scratch, opening the new resource in a tab.
• Search reusable subworkflows for Nested Workflow and For Each tasks.
• Reuse existing prompt/schema utility workflows (generate_ai_prompt, rewrite_prompt, generate_ai_schema, generate_agent_prompt).

For new workflows and major rebuilds, Genie uses a scaffold-first build flow: it creates sparse metadata/input/output/step patches first, then runs task-specialist builders that fill in task-specific configuration.

Running a Workflow

Workflows can be invoked four ways:

1. From a trigger — a trigger fires (event, schedule, webhook), looks up the workflows it's mapped to, maps its output variables onto each workflow's inputs, and enqueues a run.
2. As a tool from an agent — if the workflow's "Use as Tool" toggle is on, agents can call it like any other tool.
3. As a nested workflow — from another workflow, via the Nested Workflow or For Each task.
4. Manually — from /records/... "Run Workflow" actions, the workflow detail page's test runner, or batch operations.

1

Trigger, agent, parent workflow, or user

Each caller provides values for the workflow's declared inputs.

->

2

Published workflow

The stable version runs the task graph and records step-by-step history.

->

3

CRM update or output

The run writes fields, calls integrations, returns structured outputs, or all three.

Bulk runs and Batch History

Most bulk-automation in the product is just "run this workflow over a set of records." The sidebar Batch History view lists every active and recent batch with filter controls (workflow, record type, status, triggered-by user, date range), per-batch progress, and View / Rerun failed actions.

When Not to Use a Workflow

A workflow is not the best fit when the main problem is natural-language interpretation, tool choice, or back-and-forth conversation. In those cases, build an agent and give it a small set of tools, including any workflows it should be allowed to run.

Next Steps

• Triggers — how workflows get invoked from events.
• Tasks — full reference for task types.
• Variables — how data flows through a workflow.
• Workflows vs. agents — how to decide whether this process needs an agent too.
• Build your first workflow — guided walkthrough.
• Debug a failed workflow run — inspect runs, variables, schemas, and reruns.
• Run a workflow over many records — launch and monitor bulk workflow runs.