Workflows that call other workflows: subroutines and parallel branches

As your automations grow, you start copy-pasting the same three or four nodes into every flow: tag, notify the team, log to the CRM. That copy-paste is technical debt. The fix is sub-workflows and parallel execution: you extract the shared logic into a reusable workflow and invoke it from any other, plus run several branches at once so the flow never feels slow. This guide builds the pattern step by step with real Omnifox nodes.

The Manual trigger: the door to a sub-workflow

A normal workflow starts from an event (message, tag, deal). But if you want another workflow to call it, its trigger must be Manual (called by another workflow). That trigger doesn't listen to any external event: it only fires when a Call another workflow node invokes it. Think of it as a function you pass the current contact and conversation to.

Example: create a sub-workflow named "Register lead" with a Manual trigger and these nodes: Add tag (lead), Create deal, Log activity/note. Now any flow can run that whole routine with a single node.

Calling another workflow from the main flow

In your main workflow you add the Call another workflow node and pick "Register lead". The flow looks like this:

1. Trigger Message received (first only).
2. Send message node for the welcome.
3. Call another workflow node -> runs "Register lead".
4. Transfer to an agent node.

The order: Message received -> Send message -> Call another workflow -> Transfer to an agent. If tomorrow you change how a lead gets registered, you edit a single sub-workflow and every flow that calls it updates. That's reusing common logic.

Running branches in parallel

By default nodes run in sequence: each one waits for the previous. When you have independent tasks that don't depend on each other, the Run in parallel node launches them at once. It shines when an action might be slow (an HTTP request to an ERP, say) and you don't want to block the rest.

Example of a paid-order flow:

1. Trigger Incoming webhook with path_match order.paid.
2. Run in parallel node opening three simultaneous branches:
   • Branch A: Send WhatsApp template confirmation to the customer.
   • Branch B: HTTP request to the billing system.
   • Branch C: Post to Team in the Operations space.
3. Join branches node that waits for all three to finish.
4. Create follow-up task node for post-sale.

The order: Incoming webhook -> Run in parallel (A / B / C) -> Join branches -> Create follow-up task. The Join branches node is key: without it, you wouldn't know when every branch is done to continue safely.

Handling errors with Try/Catch

External integrations fail: an API goes down, a token expires. The Try/Catch node wraps the risky nodes and gives you an alternate branch when something blows up. In the example above, Branch B's HTTP request is the perfect candidate:

• Try: HTTP request to the billing system.
• Catch: Add internal note ("Billing failed, review manually") + Notify team by email.

That way, if the API doesn't respond, the customer still gets their confirmation (Branch A) and the team learns about the problem instead of losing it silently. Without Try/Catch, an error in one node can cut the entire flow.

Other control nodes that help

• Jump to another node: reorganize the flow without wiring long connections; handy to return to a common point after several branches.
• Loop/for each: iterate over a list (several items, for instance) repeating a block of nodes.
• Set variable: store a value at the start and reuse it in the sub-workflow and the branches.
• Find previous conversation: before creating a deal, check whether a conversation already exists to avoid duplicates.

Best practices and common mistakes

• Don't give a sub-workflow an event trigger: if you want to invoke it, its trigger must be Manual. A Message received trigger can't be called from another flow.
• Watch out for recursion: a sub-workflow that calls itself can loop. Keep the call tree shallow.
• Use Join branches after Run in parallel whenever you need everything done before moving on. If you don't care about the final order, you can let branches finish on their own.
• Reserve Try/Catch for what can truly fail (HTTP, integrations), not for all your internal logic.

Why it's worth it

Modularizing your automations lets you maintain them like clean code: one change in a single place, fast branches running together, and errors that don't take down the flow. In Omnifox you create a sub-workflow with a Manual trigger, call it with Call another workflow, and combine Run in parallel, Join branches and Try/Catch from the same visual editor. Start by extracting your repeated logic into a sub-workflow and you'll feel the difference at the first maintenance. Build your sub-workflows in Omnifox.