Skip to content
ConduitConduit

Workflows

A workflow is a named, versioned definition — a short YAML or JSON document naming its steps — that Conduit runs for you, on a schedule or on demand, against your org’s already-connected vendor tools. Because every step names its tool literally, Conduit can compute the complete set of tools a workflow will ever touch without running it. That list is what an admin reviews and approves before a workflow is allowed to do anything.

A workflow can run on a schedule or when someone starts it, under one runner identity per deployment, with full run history in the console. You write the definition yourself.

The definition format

Section titled “The definition format”

A definition has a name, optional execution limits, and an ordered list of steps. This release supports three step kinds:

  • tool — exactly one MCP tool call, named vendor__tool the same way tools already appear everywhere else in Conduit. Arguments can reference the outputs of earlier steps.
  • transform — a small, pure expression that combines earlier outputs into a new value (string concatenation, comparisons, a handful of helper functions like len(), join(), default()). No code execution, no network access — there is nothing in this language that can reach outside the run.
  • deliver — sends an emailed result. Content is escaped before it’s sent, so a ticket subject or vendor response full of stray HTML can’t do anything unexpected to the message.

llm and agent steps are not accepted. A save that includes either one is rejected. Build the definition with tool and transform steps.

A worked example:

version: 1
name: Weekly open-ticket digest
description: Counts each client's open tickets and emails the summary every Monday.


limits:
  max_tool_calls: 20
  max_duration: 5m


steps:
  - id: tickets
    kind: tool
    tool: autotask__autotask_search_tickets
    args:
      status: "open"


  - id: summary
    kind: transform
    value: "'Open tickets: ' + len(tickets.result.items)"


  - id: send
    kind: deliver
    to: email
    recipients: ["ops@example.com"]
    subject: "Weekly open-ticket digest"
    body: "{{ summary }}"

recipients can also take a single {{ ... }} template standing in for an address resolved at run time. The definition accepts that template. A run only knows its trigger’s kind (schedule, manual, or webhook), not who or what started it, so a template like {{ trigger.actor_email }} fails at the deliver step with invalid_recipient: recipient 1 ("{{ trigger.actor_email }}") did not resolve to a valid email address. Use literal addresses for recipients.

max_duration is capped at 30 minutes in this release, regardless of what you set; max_tool_calls tops out at 500.

Reviewing a workflow in the console

Section titled “Reviewing a workflow in the console”

/org/workflows lists every workflow in your org with its current state. Open one to see its detail page, in this order:

  1. What it can touch — every tool the definition can call, grouped by vendor. This is the computed tool list, and it’s shown first deliberately: approving a workflow means approving what it can touch, not reading a script and hoping you caught everything. Tools that write or delete data are marked writes; a tool on a vendor Conduit hasn’t classified yet is marked unverified rather than implying a clean bill of health (see below).
  2. Triggers — not shown on this page in this release. Ask your Conduit contact if you need to confirm a workflow’s schedule.
  3. Run history — every run, its state, duration, and per-step outcome, each tool step linking straight to its row in your audit log.
  4. Definition — the raw YAML, with Validate and Save actions. Validate runs the same checks a save does, without writing anything, so you can iterate before committing an edit.

A workflow only runs as a service account — the same kind of account you already grant vendor access to from the Access editor. Your Conduit contact sets this up as part of turning a workflow on for your org, along with its schedule; if a workflow’s detail page tells you it needs a service account attached before it can be enabled, that step hasn’t happened yet.

Why access is never automatic

Section titled “Why access is never automatic”

A workflow never grants itself anything. Its service account’s vendor access is administered exactly like any other service account, through the Access editor — nothing about creating or editing a workflow changes what that account can reach. If a workflow’s definition names a tool the service account doesn’t have access to, that step doesn’t get skipped quietly: the run fails with a visible denial, marked “refused” (not “failed” — refused is a different fact from broken) on the step, with the reason shown right there and in the run’s audit trail.

The fix is always the same: open the vendor’s Access editor, find the service account under Service accounts, and grant it the access the workflow needs. Nobody — not the workflow, not an AI client authoring it — can grant that access on its own. A human has to do it deliberately, every time.

Unverified tools

Section titled “Unverified tools”

Conduit classifies tools for most, but not all, connected vendors. When a workflow names a tool on a vendor Conduit hasn’t classified yet, author-time validation can’t confirm the tool name is real — it’s marked unverified rather than blocked outright. At run time, an unverified call is treated as requiring the highest access tier, so it fails the same way any other denial does unless the service account happens to hold that tier on the vendor. It’s an honest gap, not a silent one: the console tells you exactly which tools it couldn’t check.

Scheduling

Section titled “Scheduling”

A schedule trigger fires on a cron expression evaluated in an IANA timezone you choose — “first Monday, 8am” means 8am your time, correctly, across daylight saving. A workflow can also always be run manually by an admin, which bypasses the schedule’s overlap handling but not its limits.

Two policies govern repeated runs:

  • Overlap policy decides what happens if a run is still going when the next one is due. The default is to skip the new one rather than let a slow report stack up behind itself.
  • Catchup policy decides what happens after a gap — a deploy, an outage. The default runs the single most recent missed slot once, not once per missed interval.
Section titled “Related”