Types of Sub-Workflows in Hyperautomation

Harold Engstrom
November 8, 2019

Types of Sub-Workflows and How They Work

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.

See of FlowWright IDP in action. Let's customize your free proof of concept (POC).

Why FlowWright?

Business solutions

Enterprise Architects

Professional Developers

Software Companies (OEM)

Platform

Business Engine

Enterprise service bus

Features overview

Forms automation

Microservices

Rules Engine

Pricing

Resources

FAQ

Blogs & News

Case studies

Training center

Technical documentation

Support portal

Socials

Reviews

Share this article

Read More Featured Articles

Blog

Why Automation Is A Key Part Of Innovation...

Our most advanced Project Management tool ensures that critical tasks get executed in the right order, by the right people, in the right workstream at the right location.

Blog

Today's processes are not for tomorrow

Our most advanced Project Management tool ensures that critical tasks get executed in the right order, by the right people, in the right workstream at the right location.

Whitepaper

Real business Agility requires a dynamic model-driven approach

Our most advanced Project Management tool ensures that critical tasks get executed in the right order, by the right people, in the right workstream at the right location.