# Build a workflow

> Declare inputs, connect steps and choose the identities your workflow uses.

## Before you begin

You need owner or dashboard editor access. Connect the [account-owned tools and credentials](/en/docs/tools/credentials) your process uses. Review [unattended execution rules](/en/docs/workflows/guardrails).

## Create the pipeline

1. Open **Workflows** and choose **New workflow**.
2. Enter a name and description.
3. Add the first step with the canvas plus control.
4. Choose **Add input** for each value the process needs.
5. Set its label, type, description and **Required** setting, then choose **Save input**.
6. Configure each step, then choose **Save step**.
7. Select **Variable** to insert inputs or earlier results into step fields.
8. Choose **Save** to persist the inputs and pipeline.

Input types are **Short text**, **Long text**, **Number** and **Yes-no**. The key under **Advanced** stays fixed after creation. Removing an input requires updating steps that reference it before saving. Inputs are available to every step and get their values per run. Choose an input to see where each trigger gets its value and which steps use it.

Choose a step for the work it performs:

| Step | Configure |
| --- | --- |
| **Tool** | Connected tool, arguments and account connection or credential profile; no AI. Includes Workspace, Code Executor and Image Generation. |
| **Prompt** | Instruction and named output fields with types for structured results. |
| **Agent** | Specialist, task and briefing; it uses its own instructions, tools and file access, plus this workflow's folder. |
| **Condition** | Rules over earlier values, combined with AND/OR; no AI. |
| App function | A Tool step calling a published app function; later steps can use its output. |

## Add branches or repeat a step

1. Add a **Condition** where the process must choose a branch.
2. Configure the rules and choose **Save step**.
3. Add the matching actions to the true lane and the alternative actions to the false lane.

A condition ends its list; only the chosen lane runs, then the run completes. Put shared follow-up actions on both lanes. Inserting a condition moves later steps onto its true lane. Conditions can nest up to eight levels.

A condition chooses one lane. A repeated step processes each item of one earlier list, within your cap.

1. Open a Tool, Prompt or Agent step to repeat it.
2. Set **Repeat for each** to a single list variable.
3. Set **Max items** to a value from 1 to 20.
4. Use current-item and item-index variables in the step's arguments.
5. Choose **Save step**, then **Save**.

Read and prompt items run in parallel; write and agent items run sequentially. Item failures are collected without stopping other items by default.

> **Watch out** — A list above the cap fails the run instead of truncating it. Each repeated agent item costs a full agent run.

## Set variables and identities

1. Choose each Tool step's account connection or credential profile.
2. Insert time values through **Variable**.
3. Use **Workflow folder** for durable files and **Temporary files (this run)** for intermediate files.
4. Resolve the saved workflow's warnings before enabling triggers.

Tool steps never use members' personal connections. Different steps can use different identities; MCP steps use the server's stored account credentials. Time values are fixed at run start, in the trigger's timezone or yours for manual runs. Outputs from untaken lanes may be empty. For JSON printed by code, use subfields such as `stdout.ids`.

For new file-writing steps, select the Workspace tool named Create, write, update, copy, move or delete a Workspace file. Existing workspaceWriteFile steps still work. Check returned paths: creating or copying to a taken name adds a suffix. Update existing files when later runs must reuse them.

## Use app functions safely

1. Select a published app function in a Tool step.
2. Have an editor who manages apps save the workflow when it first uses a new app.
3. Check arguments and downstream outputs after a function changes, then save again.

Saving grants access to every published function of the apps used, including apps with their own roles. Removing an app's last step removes access on save. Duplication copies app access only when you manage apps. Partner-started app calls require continuing partner access.

Changed inputs, outputs, risk or function version block the step until you save again. Publishing or failed publication blocks app calls; **Republish needed** requires republishing the app. If a write's result is uncertain, inspect the app before retrying.

## Start from a description

1. Describe the process to the dashboard Assistant.
2. Review its complete program proposal, including branches, in one approval.
3. Approve the required credentials separately.
4. Review activation and real test runs in their own approvals.

Automatic triggers remain absent while setup or verification is pending. A duplicate copies steps, inputs, credentials and presets; it keeps no triggers, history or original folder files.

## Related

- [Run, schedule and trigger](/en/docs/workflows/triggers)
- [Workspace paths](/en/docs/workspace/paths)
- [App access](/en/docs/apps/access)