Flows

Introduction

Definitions and runs

Flows separate the template for a process from any individual execution of it:

• A flow definition describes the steps in a process, their inputs and outputs, and how those steps connect together. Definitions are reusable templates.
• A flow run is a single execution of a definition. Each run has its own inputs, outputs, status, and event history, and is identified by a flowRunId.

When you start a flow through the API, you supply a definition and a trigger, and HASH returns the flowRunId of the resulting run so that you can track, cancel, or reset it later.

Steps

A flow is composed of steps. There are a few different kinds, each documented in full in the user guide:

• Triggers start a flow. A trigger may be manual (run on demand), responsive (firing in response to data or events), or scheduled (firing at a fixed or recurring point in time).
• Actions do the work of a flow — querying, creating, updating and archiving entities, calling external APIs, and sending notifications. Actions are the most common kind of step.
• Filters introduce conditional logic, enabling branching execution paths within a single run.
• Waits pause a run until a condition is satisfied — useful for "human-in-the-loop" and long-running workflows.

It's also possible, with HASH support, to allow custom code to be inserted directly into "execution" steps, allowing you to develop your own custom actions that are executed directly within HASH, extending the range of capabilities available to flows. We'll expand this documentation when this functionality is made generally available.

Running flows

Flows can be run in three ways:

• One-off: run ad-hoc or manually by a user, as required, from the Flows page in HASH.
• Automatic: run without user input, on autopilot, by satisfying the condition(s) of a trigger — including on a recurring schedule.
• Programmatic: started by external software or function-calling agents through the HASH API.

Permissions

Flows created in a user's personal web are only ever visible to that user. Flows created in shared webs are visible to that web's members.

The API enforces these same permissions: every flow run belongs to a webId, and callers can only start, read, or manage runs in webs they have access to.