Skip to content

Build and test a workflow

Turn a repeatable process into connected steps, validate it, and inspect a manual run.

Use a workflow when work follows a repeatable sequence. Build and test it manually before adding a recurring trigger.

Build the workflow

Create a workflow

Open Workflows, choose New, and start with a blank workflow or a template. Give it a name that describes the outcome rather than the implementation.

Add the steps

Add the blocks the process needs. Available building blocks include inputs, agents, tools, generated output, conditions, repeated work, approval points, and ticket operations.

Connect blocks in execution order. Use the variable picker to pass an earlier block’s output into a later block instead of copying values manually.

Configure boundaries

For every agent or tool block, verify:

  • which agent owns the step;
  • which connection account it can use;
  • the expected input and output;
  • what should happen when a condition is not met;
  • whether an external change needs an approval point.

Keep supported external write and destructive actions behind review so a person can confirm the proposed change before it proceeds.

Validate the workflow

Use the builder’s validation feedback to resolve incomplete blocks, invalid connections, and missing inputs. A visually connected workflow can still be incomplete if a required setting is missing.

Test on demand

Run the workflow with representative input. The execution panel shows progress while the run is active. Open the completed run and inspect:

  • step order and status;
  • the input and output for each step;
  • the path selected by each condition;
  • any waiting approval or failure;
  • the final result.

If the run fails, correct the workflow and start a new test. The previous run remains available in history for comparison.

Prepare it for reuse

After a representative run succeeds, keep it as an on-demand workflow or configure an Autopilot for recurring or event-driven execution.

Describe a workflow

Instead of assembling blocks by hand, describe the process in plain language and let the builder draft the graph. Describe mode can express a linear sequence of steps, a condition or router branch, a filter or stop, a format transform, a “skip if already seen” dedupe check, and a repeated (foreach) loop. It cannot yet express a parallel branch, a classifier, or an HTTP request — add those with Build mode after the draft lands.

When your connections support it, Describe mode can also propose a deterministic write step (for example, creating a HubSpot contact) or an email to an address outside your organization. Both require you to grant a one-time approval when you activate the workflow — nothing runs unattended until you confirm it.

A described step can only reference an earlier step’s output that is in scope for it — the same rule Build mode enforces when you wire a variable by hand. The generated graph still goes through the same validation and compile check as a hand-built one before you can run it.

Expected result

Continue from here

Navigation