Workflow Examples

Real-world patterns built with Flow. Each example shows the node sequence, the capabilities used, and the key Flow Engine features involved.

Human-in-the-Loop · Forms · Database

Customer Onboarding

Collect customer details via a form, validate them, route to a manager for approval, then create the account and notify the customer.

Form Trigger → Validate Data → If / Condition → (valid) Approval (Manager) → (approved) Database Insert → Send Email → Complete
Approval Strategy
AnyOne — any single manager can approve. The workflow suspends in state 4 (Waiting) until the first approval comes in, then resumes automatically.
Error Handling
The validation node has ContinueOnFail = false. Invalid data routes to an error branch that sends a rejection email, then terminates.
Timeout Behaviour
Approval has a 48-hour deadline. On timeout, AutoOnTimeout = "escalate" — the request is forwarded to the team lead automatically.
Capabilities Used
ActorInLoop Forms Entity Messaging Identity
AI Agent · Conditional Routing · Notifications

AI-Powered Support Ticket Classification

Incoming support tickets are classified by an AI agent and routed to the right team automatically — no manual triage needed.

Webhook Trigger → AI Agent (Octopus) → Switch → (billing) Slack Message · → (technical) Assign Engineer · → (other) Send Email
AI Agent Configuration
Octopus executor with OpenAI GPT-4o. Prompt template instructs the model to classify the ticket into: billing, technical, feature-request, or other. Output port maps to Switch node branches.
Output Port Mapping
The AI Agent node uses OutputPortMapping to map model response values to execution ports. "billing" → billing port, "technical" → technical port. Unmatched → default/other.
Variable Scope
Ticket content enters as GlobalScope input data. AI classification result is merged into GlobalScope and available to all downstream nodes (Slack message, Engineer assignment, Email).
Capabilities Used
Webhooks Services (OpenAI) Messaging (Slack) Identity
Human-in-the-Loop · NofM Voting · Parallel

Multi-Level Document Approval

A contract is uploaded, reviewed by legal and finance in parallel, then requires 2 of 3 executives to sign off before finalisation.

Manual Trigger → Parallel Fork → Approval (Legal) + Approval (Finance) → Parallel Join → Approval NofM (2 of 3 Exec) → Finalise
Parallel Execution
Parallel Fork pushes both Legal and Finance approval nodes onto the execution stack simultaneously. Both run concurrently. Parallel Join waits for both to complete before continuing.
NofM Approval Strategy
Executive approval uses Strategy = NofM with RequiredCount = 2 and 3 actors. Any 2 of the 3 executives approving is sufficient. The third's vote is ignored once the threshold is met.
Suspension Duration
Each approval node suspends in state 4 (Waiting). The workflow can stay suspended for days. State is persisted in SuspendedExecution table and resumed via ExecuteContinuationAsync when decisions arrive.
Capabilities Used
ActorInLoop Execution (Parallel) Messaging Entity (Document)
Scheduled · Database · Error Handling

Nightly Database Sync

Every night at 2am, pull records from a PostgreSQL source, transform them, and upsert into Data Ocean. Alert on-call if anything fails.

Schedule (Cron 0 2 * * *) → Try Block → PostgreSQL Query → JSON Transform → Loop → Database Upsert → (catch) Slack Alert → (finally) Log Result
Loop Scope
The Loop node iterates over the PostgreSQL result set. Each iteration's current record is stored in LoopScope and accessible to the Database Upsert node. LoopScope resets per iteration.
Try/Catch/Finally
The PostgreSQL query and transform are inside a Try Block. If any node fails, the Catch branch routes to Slack alert with the error from TryCatchScope. Finally always runs to log the result — success or failure.
Node Timeout
PostgreSQL Query has Timeout = 300 seconds, TimeoutBehavior = "Error". If the query runs over 5 minutes, it triggers the catch branch automatically.
Capabilities Used
Datasource (PostgreSQL) Entity (Data Ocean) Messaging (Slack) Rules
Sub-Workflow · Reusable · Parallel

Reusable Notification Sub-Workflow

Build a send-notification workflow once and call it from any other workflow using the Sub-Workflow node. Channel selection (Slack, Email, WhatsApp) is parameterised at call time.

[Any Workflow] → Sub-Workflow: notify → (with params) Webhook Trigger (notify) → Switch (channel) → Slack / Email / WhatsApp → Return
Sub-Workflow Node
The Sub-Workflow executor invokes a separate ProcessThread with its own execution context. Input data (channel, message, recipient) is passed via GlobalScope. The parent workflow waits for the sub-workflow to complete before continuing.
Reusability
The notify sub-workflow is defined once in a shared project. Any workflow in the tenant can invoke it. Changes to the notification logic propagate automatically to all callers.
Capabilities Used
Process (Sub-workflow) Messaging (Slack) Messaging (Email) Messaging (WhatsApp)
Execution Context
The sub-workflow runs as a new ProcessThread with its own ProcessThreadExecutionContext and ThreadScope. It does not pollute the parent's variable scopes. Only the return value is merged back into GlobalScope.

Ready to build your own?

Start with the get-started guide or explore the architecture to understand how it all fits together.

Get Started Architecture