For the complete documentation index, see llms.txt. This page is also available as Markdown.

Automate

Turn a known part of an operational process into a defined, repeatable execution path.

Use Automate when part of an operational process is understood well enough to run through a defined, repeatable path.

A common progression is that people first handle messy cases manually or with the Agent, then move stable parts into Workflows once the triggers, rules, data and exception boundaries are clearer.

The Automate list groups Workflows by trigger type and shows current Draft or Active state, recent run activity and builder actions.

Start with the process, not the canvas

Before wiring actions together, define:

  • what starts the work;

  • what a correct business result looks like;

  • which systems and information are authoritative;

  • what can be handled deterministically;

  • where judgement or missing information requires a person;

  • what should happen when something fails.

Then use the builder mechanics to encode that path.

Workflow anatomy: one defined path from Trigger through actions, branches and data flow, optional Request Decision or Request Input boundaries, external side effects or output, with Monitoring evidence captured across the run and Draft/Published as states of the same Workflow.

Build the execution

Use Build a workflow for triggers, actions, data flow and canvas mechanics.

Use Human handoffs when the running Workflow must deliberately pause for a human decision or input. Those handoffs create operator-facing Requests.

Test before live execution

Use Test and publish to run the Draft, validate behaviour, publish the version used by production and configure supported schedules.

Builder Runs and Tests are real executions. External actions can have real side effects, so choose test data and connected systems accordingly.

After execution, use Monitoring to inspect what actually happened across runs.

Expose structured operator access

Use Publish apps & APIs when a published Workflow should be started or used through an operator-facing app or supported programmatic surface.

Operators use those published interfaces under Workflow apps.

Add reusable context and capability

If the execution needs maintained instructions, structured data, reference material or files, use Intelligence rather than embedding everything directly into Workflow logic.

Where to go next

  • Design and build the path → Build a workflow

  • Add human decision points → Human handoffs

  • Run, test and publish → Test and publish

  • Publish an operator interface → Publish apps & APIs

  • Inspect live execution → Monitoring

Last updated

Was this helpful?