Skip to main content

Workflows

A workflow is a reusable, multi-step process. You draw it on a canvas as a graph of nodes (steps) joined by connections, and FYAI runs it end to end. Each run of a workflow is a mission.

Use a workflow when the same sequence should happen every time: research then write, triage then route, check then wait then check again. For an open-ended conversation, use chat with an agent or team instead.

Find workflows under Build → Workflows.

What a workflow contains​

PartWhat it is
Name and DescriptionShown on the workflow list and in the mission picker.
NodesThe steps. Every workflow has exactly one Trigger node, where every run starts.
ConnectionsArrows from one node's output handle to another node's input. A run follows them.
AttributesInputs people fill in when they launch the workflow from Missions. See Workflow Attributes.

Node types​

The builder's Nodes palette offers 13 node types:

Palette nameWhat it does
TriggerThe start of every run. Also where you set a schedule.
AgentSends a message to one agent and waits for its reply.
TeamSends a message to a team and waits for the team's result.
FunctionCalls one function directly, with arguments you set. No model is involved.
ConditionSends the run down one of several named branches.
Loop Start / Loop EndRepeat the steps between them, a fixed number of times or once per item in a list.
MissionRuns another workflow as a sub-workflow and waits for it to finish.
WaitPauses for a set time (up to 24 hours).
ApprovalPauses until a person approves or rejects.
Kill SwitchLets you stop runs at this point by flipping a switch, including runs already in progress.
Test CaseDescribes a test scenario and shows the Run All Tests button. Not usable in a saved workflow yet — see Testing Workflows.
ElementShows a catalog element on the mission canvas. Its element is set through the API.

Every field of every node is listed in the Workflow Node Reference.

How a run executes​

  1. The run starts at the Trigger node.
  2. After each node finishes, the run follows every connection leaving it. When a node has two or more outgoing connections, the next nodes run in parallel.
  3. A node with two or more incoming connections waits, by default, until all of its parents have finished (an AND-join). You can change this per node with Join Mode — see Designing Workflows.
  4. A Condition node follows only the one branch whose rule matches.
  5. A loop repeats the nodes between Loop Start and Loop End, then carries on from the connections leaving Loop End.
  6. The run ends when there is nothing left to run.

If a node fails (after any retries you configured), the whole run fails and stops. A rejected or timed-out Approval node also fails the run.

Each node's output is stored so later nodes can use it. You insert it into a prompt or argument as a variable such as ${node_2_result}, and attribute values as ${attribute.topic}. See Passing Data Between Steps.

How runs start​

StartHow
Missions pagePick the workflow under Build → Missions, fill in its attributes, and launch. This is the only way to supply attribute values.
Run Workflow buttonThe play button in the builder toolbar starts a run straight away, with no attribute values, and opens it on the mission canvas.
Run on the workflow listOpens Missions with this workflow selected.
ScheduleSet the Trigger node to Scheduled. See Scheduling Workflows.
WebhookAn external system posts to a webhook whose Linked Workflow is this workflow. See Webhooks.
Programs, sub-workflows, API, Claude CodeA program activity, a parent workflow's Mission node, the Platform API or the Platform MCP server.

The run's start method is recorded as its Trigger (Manual, Schedule, Webhook, Program, API, Claude Code) and shown in the workflow's execution history.

note

The Trigger node's Event-based type is saved with the workflow but nothing currently starts a run from it. Use a schedule or a webhook to start runs automatically.

Statuses on the workflow list​

The list shows a status badge for each workflow. You don't set it — FYAI derives it:

StatusMeaning
DraftNever edited since it was created and never run.
LiveEdited at least once since it was created, or run at least once.
ArchivedDeactivated. An archived workflow can't be run: Run is disabled, schedules don't fire, and webhooks are refused.

Draft and Live behave the same way. A Draft workflow can be scheduled and triggered.

The workflow list​

Build → Workflows shows each workflow with its Runs, Success rate, Avg Cost and Last Run, plus a summary bar (Workflows, Total Runs, Avg Success, Total Cost, Tokens Used). You can search by name, description or tag, filter by status (All, Live, Draft, Archived), sort (Recently Updated, Name, Status, Most Runs), and switch between grid and list views.

Each workflow has a Run button and a menu with View, Edit, Clone and Delete. Clone makes a copy named "… (copy)" with the same nodes, connections, attributes, description and tags. Schedules, webhooks, run state and run history are not copied.

Who can do what​

ActionNeeds
Create, edit, clone or delete a workflowProject Editor role or higher (or an organisation Owner/Admin).
Run a workflowEditor or higher, or an explicit run grant for that workflow.

See Members and Roles.

Run state​

Each workflow has a small key–value store that persists between runs, called run state. It is read and written through the API (/workflows/{workflow_id}/run-state) or the Platform MCP server, not from inside a node. Webhook deferral records are also written there. See Ralph Loops.