Workflow blocks - Attio Docs

Attio Workflows is a visual automation builder that lets workspace members define sequences of automated actions. For example: “when a deal moves to Closed Won, send a Slack message and create an onboarding task”. Each step in that sequence is called a block. Attio ships a set of built-in blocks, but your app can add its own. Workflow blocks let your app contribute custom blocks to the Workflows builder. Once your app is installed, those blocks appear in the block picker alongside Attio’s built-in blocks, and workspace members can drag them into any workflow and configure them without writing code. There are two kinds of block your app can define:

Trigger blocks start a new workflow run when something happens in an external system (e.g. a webhook arrives from a third-party service).
Step blocks run as part of an already-running workflow (e.g. call an external API, transform data, or wait for an async callback before continuing).

The type property in block.ts — not the folder or file name — determines which files are required and which handler functions are available.

Trigger vs step

The two block types serve different roles and require different files. The table below summarises the key differences:

	Trigger (`type: "trigger"`)	Step (`type: "step"`)
Role	Starts a workflow run	Runs as part of an existing workflow run
Typical use case	Subscribing to a third-party webhook	Calling an external API, transforming data, waiting on a callback
Required files	`activate.ts`, `trigger.ts`, `deactivate.ts`, `configurator.tsx`	`execute.ts`, `configurator.tsx` (+ optional `finish.ts`)

Inputs and outputs

Every workflow block has two data contracts: Inputs: config schema The config schema describes the fields workspace members fill in when they add the block to a workflow. configurator.tsx renders an input for each field so members can fill in values. See Config schema for available field types and Configurator for the input components. Outputs: outcome schema When a handler finishes, it signals an outcome, for example “email sent” or “send failed”. The outcome schema describes what data each outcome carries, which determines what variables downstream steps can use in the workflow editor. You declare outcomes in configurator.tsx using the Outcome component. See Outcome schema for available node types.

Guide

Start here to build a complete working block. The guide walks through both a step block and a trigger block end to end, with all required files.

Building workflow blocks

Step-by-step guide to building a step block and a trigger block.

Reference

Use these pages to look up individual APIs, file requirements, and schema node types while building.

File structure

Folder layout and required files for trigger and step blocks.

Block lifecycle

When each handler is called and what the return values do.

Block definition

Declare a block’s id, type, title, and config schema.

Config schema

All node types available for the block’s configurable fields.

Outcome schema

Node types for typing outcome data returned from handlers.

Configurator

Render config inputs and declare outcomes in the workflow editor.

​Trigger vs step

​Inputs and outputs

​Guide