How a workflow executes

Cloudgate resolves the incoming route, performs gateway access checks, and starts execution at the action's entry node. The graph's connections determine what happens next.

The request lifecycle#

1. The gateway identifies the workspace, environment, controller path, action route, and HTTP method.
2. Applicable API access, network, and authentication checks run.
3. The workflow starts at its configured entry node.
4. Each node receives the current execution context and can produce a named result.
5. The final result is formatted according to the action's response settings.

Most nodes continue to their ordinary next connection. A Condition chooses its true or false connection and returns through that branch. A Decision takes the first enabled matching row with a connected target. These branches do not also execute an unrelated ordinary next path in the same hop.

Data lives in the execution context#

Request values and prior node results become selectors such as ${body} and ${FetchOrder}. A later node can only use a result after the producing node has executed on that path.

Session values are execution data, not durable application storage. Persist business records in a database. Delayed work should carry the identifiers it needs in its own input rather than relying on an old execution's stored keys.

Errors and completion#

Function, HTTP Request, and Database failures can stop execution before the next node. Inspect the failed node and action log rather than assuming every connected step ran.

A terminal node has no next step. Keep the response-producing node explicit so adding another operation does not accidentally change the API response.

Background work and limits#

An asynchronous action can acknowledge receipt before background processing finishes. A background branch also has its own completion timing. A receipt is not proof that downstream work succeeded.

A Schedule node creates or updates a later job; it does not call the target inline. Workflow execution has time and step limits that depend on the running server configuration. Design bounded paths and use scheduled workers for recurring work rather than an unbounded graph loop.