Workflows

Workflows

Auton8 models business processes in BPMN 2.0, deploys them to a Flowable engine, and gives you the execution history to trace what actually happened.

The studio

Workflows → Workflows opens the modeller. It is a full BPMN canvas: draw the process, configure each node, save drafts, then publish.

The lifecycle is deliberately two-step:

1. Save a draft. Drafts live in Auton8's database and are versioned. They are not executable yet.
2. Publish/deploy. The model goes to Flowable, which owns execution from that point.

Because drafts are versioned, you can iterate without disturbing running processes.

Node types

The studio supports the BPMN 2.0 node set the engine can actually execute — events, tasks, gateways, subprocesses. The studio's own reference panel lists the full set it can model and execute, which is the authoritative answer as it changes.

Three node kinds matter most in practice:

• User tasks — work assigned to a person; these become entries in Tasks.
• Service tasks — work the platform does. See Behaviors below.
• Script tasks — JavaScript evaluated as part of the process; the body is stored inline in the model.

Behaviors: making a process act on Auton8

A service task can run a behavior — a curated routine inside Auton8 rather than an arbitrary HTTP call. This is how a process reads or writes records, sends notifications, and so on.

Mechanically, service tasks are routed to Auton8 through a fixed Flowable bean (${autonateBehaviorDelegate}), and the callback is authenticated with a shared secret. You do not need to configure that per task — it is engine-level wiring — but it is why a misconfigured CallbackSharedSecret breaks every service task at once.

Starting a process from an event

A workflow can be started by a Dapr pub/sub event rather than by a person. The studio configures the topic to listen on, and Auton8 subscribes.

Executions

Workflows → Workflow Executions is the operational view: what is running, what finished, what failed.

For any execution you can:

• see its current step, and the path it took
• open the diagram with live state overlaid, including the latest error per activity
• read the history — step by step, with error messages and stack traces where they occurred
• inspect variables, including their history over time
• pause, resume, or delete a run, subject to permission

Deleting removes the run from both Auton8 and Flowable — the confirmation says so because it is not a local-only action.

Tasks

User tasks assigned to you appear under My Tasks on the Home page; tasks assigned to people you supervise appear under Team Tasks. Completing a task advances the process.

Querying workflows

Five AQL entities cover this domain, which is usually faster than clicking through executions:

Entity	Holds
Workflows	The models themselves
WorkflowExecutions	Runs
WorkflowTasks	User tasks
WorkflowHistory	Step-by-step history
WorkflowVariables	Process variables
Flows	The convenience entity used in most examples
WorkflowAnalytics	Aggregated shapes for dashboards

For example, recent runs by status:

FROM Flows ORDER BY Total DESC COLUMNS(Status, COUNT() AS Total) GROUP(Status)

Or a time window:

FROM Flows WHERE BETWEEN(StartDate, 2w ago, NOW) ORDER BY StartDate DESC

See Queries-and-Dashboards for the language.

When Flowable is unavailable

Workflow modelling, deployment and execution all require the engine. The rest of Auton8 — records, documents, queries, data — keeps working. That separation is deliberate, and it is why the workflow specs are traited so CI can exclude them where the engine is not hosted.