Sub-workflows (or sub-processes) are a key part of building scalable workflow applications. Instead of letting a single model grow huge and hard to maintain, you can break logic into reusable sub-workflows that handle specific tasks. In this article, we explain the main types of sub-workflows in FlowWright and how to decide which type to use in your process design.
If you want to see these patterns in action, you can also schedule a FlowWright demo to explore how sub-workflows fit into your existing processes.
What Are Sub-Workflows in FlowWright?
A sub-workflow is a workflow that is called from another “parent” workflow to perform a specific part of the overall process. Instead of repeating the same steps across multiple models, you move that logic into a sub-workflow and call it whenever it is needed. This improves reusability, simplifies maintenance, and makes complex enterprise processes easier to reason about.
Reusability is one of the biggest reasons to use sub-workflows. Many business functions repeat across a process or even across multiple processes. For example, updating a milestone in SugarCRM can occur several times during an automated sales process. Instead of duplicating those steps, you can create a “Update CRM Milestone” sub-workflow once and call it whenever a workflow reaches that stage.
Types of Sub-Workflows in FlowWright
FlowWright provides two main types of sub-workflow steps. Both let a parent workflow call a child workflow, but they behave differently and are useful in different scenarios.
Standard Sub-Workflow Step
The standard sub-workflow step calls a predefined child workflow from the parent. You design the child once, deploy it, and then reuse it wherever that function is needed. This is ideal for repeatable operations such as sending notifications, updating external systems, or performing a common validation routine.
Dynamic Sub-Workflow Step
A dynamic sub-workflow step lets the parent decide at runtime which child workflow to execute. Instead of hard-wiring a single child process, you can choose one based on data, configuration, or business rules. This works well for multi-tenant scenarios, customer-specific logic, or situations where the same parent workflow must route to different implementations.
Synchronized vs. Non-Synchronized Sub-Workflows
In FlowWright, the standard sub-workflow step can run in two modes, depending on whether the parent should wait for the child to finish.
Synchronized Sub-Workflow
In synchronized mode, the parent workflow waits until the child workflow completes before moving on. Use this when downstream steps depend on the child’s result, such as waiting for an approval decision, a document to be generated, or a third-party system to confirm an update.
Non-Synchronized Sub-Workflow
In non-synchronized mode, the parent workflow starts the child workflow and then continues immediately. This is useful for background work that does not block the main journey, such as logging, sending non-critical notifications, or updating secondary systems.
Both modes are important when you are converting manual work into automated workflows. In some cases, the parent must wait for the child to finish before continuing; in others, it is more efficient to let the parent keep running while the child handles background tasks. Choosing the right mode is a core design decision for reliable, scalable workflow automation.
Best Practices for Designing Sub-Workflows
When you model types of sub-workflows in FlowWright, a few design practices can improve performance and maintainability:
• Keep sub-workflows focused on a single responsibility (for example, “Send Invoice Email”).
• Reuse sub-workflows for cross-cutting concerns such as logging, notifications, or integrations.
• Use synchronized mode when downstream steps depend on the child output.
• Use non-synchronized mode for background work that does not affect the main outcome.
• Document inputs and outputs so other designers can safely reuse each sub-workflow.
Contact us today to understand more about sub-workflow processing for your workflow automated business process.






