Workflows

Chain tools into governed workflows

A workflow composes your generated tools into a single, reviewable process: a graph of nodes connected by edges that set the order of execution. You assemble the steps once, gate any writes behind human approval, and then expose the whole thing as one MCP tool. This page walks through each step and shows exactly what you get back.

  1. 1

    Create a workflow

    Console -> Workflows

    From the console, open Workflows and create a new one. You start with an empty canvas: a named, versioned graph that will hold your nodes and the edges between them. Nothing runs yet, and nothing is exposed.

    What you'll see

    An empty workflow canvas.

    This is where the product screen for this step will appear.

  2. 2

    Add nodes

    Workflows -> Add node

    Each step in the process is a node. DataTether supports a fixed set of node types, so every workflow stays predictable and reviewable:

    Node typesNodes available
    • tool: call a generated tool from a connected service.
    • condition: branch on a value to choose what runs next.
    • transform: reshape data between steps.
    • input: accept arguments into the workflow.
    • llm: reason over the result of a step.
    • ui_node: render a UI surface for the user.
    • code: run validated logic.
  3. 3

    Connect nodes into a sequence

    Workflows -> Connect

    Draw edges between nodes to set the order of execution. The graph is acyclic by design: each edge points forward, so the process always has a clear beginning and end. If you try to connect nodes in a way that loops back on itself, DataTether rejects the edge and reports Adding this edge would create a cycle, which keeps every workflow safe to run and simple to reason about.

    What you'll seeOrder validated

    The edge is accepted and the execution order is fixed:

    • Each edge defines which node runs after another.
    • The graph stays acyclic, so there are no loops.
    • An edge that would form a cycle is rejected before it is saved.
  4. 4

    Gate a write behind confirmation

    Workflows -> Step settings

    When a step writes back to a source system, you can require human approval before it runs. The workflow reaches that step, pauses, and surfaces the proposed change for a person to approve or reject. Read steps continue as normal; only the gated write waits. See the Security and governance page for how approvals, validation, and audit fit together.

    What you'll seeApproval required

    The workflow holds at the write step until a person decides:

    • The proposed change is shown with its arguments before anything is committed.
    • Execution resumes only after the step is approved.
    • A rejection stops the write and ends the run without side effects.
  5. 5

    Run the workflow

    Workflows -> Run

    Run the whole workflow, or execute a single node while you are building it. Either way, execution happens under the requesting user's access, so connection scopes and row-level rules stay in force for every step. Each node returns a result, and the workflow produces a final output.

    What you'll seeRun complete
    {
  "nodeResults": {
    "input":     { "status": "completed", "data": { "region": "EU" } },
    "list_step": { "status": "completed", "data": { "count": 3 } },
    "transform": { "status": "completed", "data": { "topOrder": "0001" } }
  },
  "final": {
    "region": "EU",
    "matched": 3,
    "selected": "0001"
  },
  "status": "completed"
}
  6. 6

    Expose the workflow as a tool

    Workflows -> Expose

    Once the workflow runs the way you expect, expose it. The entire multi-step process becomes a single callable MCP tool. Other clients see one tool with one set of inputs, while every node, edge, and approval gate stays governed exactly as you configured it.

    What you'll seeExposed as a tool

    The workflow is now a first-class tool on your endpoint:

    • It appears in the tool list alongside your other generated tools.
    • A client calls it once and the workflow runs the full sequence.
    • Access, validation, and any approval gates apply on every call.

Related