Server-side flows

A server-side flow processes a project's content in the workspace, with no local checkout and no CLI. It runs the same pipelines as kapi, over the blocks the server holds.

A flow runs on the server in two ways: as the flow a convergence run drives, or from an automation rule's run_flow action. Either way it runs in the background, reads the project's blocks, streams them through its tools and writes the results back.

How a server-side flow runs

Progress and the outcome appear in the project's Runs view, and in kapi up's terminal view when the run was started from a checkout.

Triggering flows

As part of a run

Every run drives the project's default flow: recycle from memory, draft, check. Start one from the Runs view with Run now, from a checkout with kapi up, or let the project's bowrain.converge policy start one on every push.

From an automation rule

An automation rule runs a named flow when an event fires. See Automation for the triggers and for creating rules.

Example: draft content when it arrives from a push:

{
  "name": "auto-draft",
  "trigger": "connector.push.completed",
  "action": {
    "type": "run_flow",
    "config": {
      "flow": "translate",
      "target_locales": "fr,de,ja"
    }
  }
}

From the web app

The Bowrain web app exposes a flow and automation editor under Project > Automations, with three tabs:

1. Runs: run history (see Automation).
2. Rules: trigger, conditions, and ordered actions. A run_flow action selects a flow from the project's flow registry.
3. Flows: the flow canvas, the same visual editor the desktop app renders. It lists the built-in flows beside the project's stored flows, and you edit the stored ones as a reader → tool(s) → writer graph. Transformers such as redaction and normalization are ordinary ordered steps, and the server validates their placement when it builds the flow.

A flow works the same on content from any connector. The graph names no connector, so content from a content platform, a design tool, a repository or a developer's checkout goes through the same steps.

Event flow

The diagram shows the developer route, where a checkout pushes and the server runs the flow. Content from any other connector takes the same path on the server.

Managing flow definitions

Project flow definitions are stored server-side and exposed through a project-scoped REST API. The flow editor in the web app (and the desktop app) drives these endpoints; automations reference a flow by its id.

Method	Path	Description
GET	/api/v1/:ws/:id/flows	List flows (built-in catalog + project flows)
GET	/api/v1/:ws/:id/flows/:flowId	Get one flow (built-in or project)
POST	/api/v1/:ws/:id/flows	Create a project flow
PUT	/api/v1/:ws/:id/flows/:flowId	Replace a project flow
DELETE	/api/v1/:ws/:id/flows/:flowId	Delete a project flow

Built-in flows are read-only; the server rejects writes to a flow whose id collides with a built-in. Mutations require the manage_automation permission.

A flow definition is a node/edge graph (reader → tool(s) → writer), so the visual editor can open and save it without loss:

curl -X POST https://app.bowrain.cloud/api/v1/acme/proj-1/flows \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "translate-with-checks",
    "description": "Translate then run quality checks",
    "nodes": [
      {"id": "reader", "type": "reader", "name": "auto", "position": {"x": 0, "y": 0}},
      {"id": "translate", "type": "tool", "name": "translate", "position": {"x": 250, "y": 0}},
      {"id": "qa", "type": "tool", "name": "qa", "position": {"x": 500, "y": 0}},
      {"id": "writer", "type": "writer", "name": "auto", "position": {"x": 750, "y": 0}}
    ],
    "edges": [
      {"id": "e1", "source": "reader", "target": "translate"},
      {"id": "e2", "source": "translate", "target": "qa"},
      {"id": "e3", "source": "qa", "target": "writer"}
    ]
  }'

On the developer route, flow definitions can also live in the directory a project's recipe names with flows_dir: and be pushed with the rest of the project.

Composing multi-step work

Put multi-step work inside one flow definition: the node graph above chains translate and qa in one run. One flow cannot start another. Automations react to content events such as connector.push.completed with a fixed set of actions (see Automation). No automation trigger fires when a flow finishes, so a rule cannot chain on one. See Automation > Loop prevention for how Bowrain bounds event-driven work.

Related

• Automation: event-driven automation rules
• Connectors: where flow input comes from
• Flows on the developer route: authoring flows in a project
• kapi up: catch a connected project up (push → run → pull)