Workflow Builder

The Workflow Builder is a visual canvas for automations. You place nodes, connect them, publish, and Fabric runs the graph durably: every node's input, output and timing is recorded, failed steps retry, and a run survives a restart of the service executing it.

What a workflow is

A workflow is a directed graph. One trigger node decides when the graph runs; every other node is a step that consumes the output of the nodes before it.

Build a workflow

Search for the latest AI news, summarise the results,
and send a Slack message to #technology with the summary.

Triggers

The trigger node's Trigger Type decides how runs start.

Ticking Enable Webhook Trigger in the publish dialog is what arms the endpoint: it sets the workflow's trigger type to Webhook and mints the signing secret. A workflow published without it refuses calls with 403, however published it looks. A cron on the trigger node set to Schedule makes the workflow schedule-triggered on publish; if you enable the webhook as well, the webhook wins as the workflow's trigger type.

A schedule is read from the trigger node's Schedule (cron) field, in five- or six-field form — for example 0 9 * * 1-5 for 09:00, Monday to Friday. That field carries a default, so it is the Trigger Type that decides whether a schedule is created, not the presence of a cron. Fabric registers it when you publish and removes it when you unpublish, pause or archive the workflow.

Nodes

Core nodes

Integration actions

The palette carries 55 integration actions on top of the three core nodes. An action appears only when Fabric ships an executor for it, so the palette never offers a node that nothing can run — you still have to connect the service it uses.

AI

Communication

CRM

Data

Design

Developer

Productivity

Sales

Support

Web

Six further connections — Confluence, Databricks Vector Search, Google Drive, Microsoft Teams, NHTSA Vehicle Data and Notion — are knowledge sources rather than workflow actions. They are configured in the same place but do not add nodes to the canvas.

Passing data between nodes

Any text field on any node can reference values produced earlier. Fabric substitutes them just before the node runs.

A webhook body is spread across the top level — each key becomes a variable of that name — so POSTing {"body": "..."} gives you {{body}}. Each node's own output fields are listed in the template fields of the nodes after it, which autocomplete every reference available at that point.

Labels are how references resolve, so two nodes sharing one label are ambiguous. Some default labels collide across integrations — GitHub and GitLab both offer a Get File Contents — so rename one of them if you use both on a canvas.

Conditions

A Condition node evaluates one expression and routes the run down its true or false edge.

{{Generate Text.text}}.includes("negative")
{{HTTP Request.status}} == 200
{{Score.value}} > 7
{{Out.text}}.includes("failed") && {{Out.text}}.includes("windows")

Supported forms:

• substring tests — .includes("...")
• comparisons — ==, !=, ===, !==, >, <, >=, <=
• logical operators — &&, ||, !, with parentheses

An expression with no operator is a truthiness check on the value. Expressions are read by a restricted parser rather than a JavaScript engine, so function calls other than .includes(), assignment and arbitrary code are not available.

That parser also narrows the characters it will consider: : / @ # % ? ; brackets, braces and anything non-ASCII are dropped from both sides before comparison. Equality against a literal still holds, since both sides lose the same characters, but a substring test whose needle contains one will not match what you wrote — searching for user@example.com compares against userexample.com. Match on a plainer fragment.

Generating a workflow with AI

The prompt box in the editor drafts graphs in three modes:

• Create — replace the canvas with a new graph
• Modify — change the existing graph
• Append — add steps to the end

Generation can emit eleven node types: the trigger, AI text and image, HTTP request, Firecrawl scrape and search, condition, Linear ticket, email, Slack message and MCP tool. Everything else — GitHub, Jira, Stripe, the rest of the palette — you add yourself. Ask for one of those in the prompt and the graph is rejected rather than saved half-working, since its edges would reference a node nothing can run.

Generation uses your configured AI provider and model.

Integrations and credentials

Connect services under Workflows → Integrations. A connection belongs to the account or organization that created it. Secrets are encrypted before they are stored and masked when displayed, and Test Connection calls the live service, so a green result means the credential works rather than merely that it is well-formed.

Publishing and versions

Publishing a workflow:

1. Saves the current graph as a numbered version, with the changelog you type
2. Generates the webhook URL and signing secret, if you enable the webhook trigger
3. Registers the schedule, if the trigger node's type is Schedule

Version History lists every published version. Rolling back restores that version's graph onto the canvas and records the restore as a new version, so the history stays append-only.

Webhook triggers

A published workflow with a webhook trigger accepts:

POST /api/workflows/trigger/{workflowId}

Sign the request body and send your input as JSON:

The webhook secret is shown when you publish with webhooks enabled. Copy it then: while the workflow stays published, nothing shows it again. Never send the secret itself as a header — you send a hash computed from it, over the exact bytes of the body you are posting.

SIGNATURE=$(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$SECRET" -r | cut -d' ' -f1)
curl -X POST "$URL" \
  -H "Content-Type: application/json" \
  -H "X-Workflow-Signature: sha256=$SIGNATURE" \
  -d "$BODY"

A successful call returns the executionId of the run it started, which matches the run in the workflow's run history.

Running and monitoring

The execution panel, and the run history for past runs, show each node's status, output, error and duration.

A failed node is tried up to three times, with the wait doubling from one second.

Nodes that write to an external service are deliberately not retried after an infrastructure error, because the write may already have landed and a retry would duplicate it. That covers creating a ticket, sending a message, filing an issue, uploading a file and publishing a site — and the MCP Tool node, whose tool could be doing any of those. Those nodes fail the run instead; the execution log shows which node was in flight.

Statuses

Limits

Troubleshooting

A webhook call returns 403. Either the workflow is not live — a draft, paused or archived — or its trigger type is not Webhook. Republishing with Enable Webhook Trigger ticked fixes the second case.

A scheduled workflow stopped firing. Pausing, unpublishing or archiving removes the schedule; activating or republishing puts it back. A changed cron expression takes effect when you save.

A condition always takes the same branch. Check the expression against the forms listed above, and read the referenced node's real output in the run history.

Next steps