Workflow Node

The Workflow node allows you to trigger another workflow from within your current workflow. This makes it possible to break complex processes into smaller, reusable workflows, improving modularity and maintainability.

With the Workflow node, you can:

• Trigger child workflows based on conditions or events
• Pass data from the current workflow to the triggered workflow
• Reuse common automation logic across multiple workflows
• Build hierarchical workflows for complex business processes

The Workflow node is ideal for enterprise automation where processes need to be standardized, reusable, and easy to manage. For example, you could trigger an invoice processing workflow from an order management workflow, or call a notification workflow after a task is completed. You can also send parameters to the other workflow, allowing dynamic control over the triggered workflow’s execution.

A workflow can call itself recursively. It’s recommended to define an exit condition to avoid creating an infinite loop.

The timeout for each workflow can be configured using the WORKFLOW_TIMEOUT_SECONDS environment variable. For more information checkout Customizing Workflow Configuration.

Example 1 - Reusable Logging Workflow

This example shows how you can centralise common tasks like logging, into a reusable workflow that other workflows can call.
Consider a centralised workflow that inserts event logs in a database. So any workflow that performs a critical task inserts a log.

For this example we'll have a child and a parent workflow.

Child Workflow
Child workflow will be the centralised logging workflow that adds entries to a database. Here's an overview of the child workflow (logger):

For this example, the data that the child workflow receives is in the following format:

{
  "logged_by": "Authentication System",
  "message": "New user created"
}

The child workflow receives the data and performs an insert operation to the database and returns a response based on the success of the insert operation.

Result (Child Workflow):

Parent Workflow
We will create a workflow, which needs to log the event data in the database. This workflow:

• Adds an employee to the company database.
• Sends a welcome email to the employee.
• Adds a failure/success log using the earlier created workflow using workflow node.

For this example, the data that the parent workflow receives is in the following format:

{
  "email": "[email protected]",
  "name": "Employee",
  "phone_number": "+1111111111"
}

1. Create a DB Node to insert the data to the DB named addEmployee.
2. Branch the addEmployee node.
   Click the branch icon to branch the addEmployee node. From the green port, create an SMTP Node to send a success mail to the employee named mailTheEmployee.
   From the red port, create a workflow node and name it logFailure.
3. From the mailTheEmployee node, create a workflow node and name it logSuccess.
4. Configure the logSuccess and logFailure nodes.

Result
Both success and failure paths create a log entry, ensuring that the parent workflow’s actions are traceable.

Example 2 - Build a Reusable Notification Workflow

Often, different workflows need to alert the right person when an incident occurs. To avoid repeating the same notification steps in every workflow, we can create one shared workflow for sending notifications.

For this example:

• The parent workflow deletes an S3 object and then calls the child workflow.
• The child workflow sends notifications.
• The parent workflow checks if the notification succeeded.

Child Workflow

Following is the parameter structure for the child workflow:

{
    "incident": "Payment Failure",
    "raised_by": "Monitoring System",
    "recipients": ["[email protected]"],
    "severity": "critical"
}

The workflow does the following work

• Extract recipient details from the database.
• Extrace the severity level from the parameters
• Triggers the appropriate notification channels.

At the end of the workflow, Response nodes return structured output. These values can then be consumed by any parent workflow that triggers this one.

Parent Workflow
Now that the child workflow is defined, let’s look at how another parent workflow can invoke it using the Workflow node.

We are creating a new workflow that removes an object from an AWS S3 bucket and then notify the organisation's AWS team.
Here's an overview of the parent workflow:

We add a node that deletes an object from S3 and name it removeObjectFromAWSS3. Then, from this node, we create an outgoing connection to a Run Workflow node named notificationSystem.

Here's the configuration for notificationSystem node. This follow the same format as given in child workflow:

After the child workflow completes, we evaluate its response to determine whether the notification was successful. For this, we use an If Condition node named checkNotificationSuccess, which checks: notificationSystem.data.success == true

After running the workflow, we'll receive an email like this: