Documentation
Start typing to search…

Subflow Trigger

Definition

The Subflow Trigger allows you to create a Zenphi flow that can be invoked as a subflow from another Zenphi flow. Think of it as a modular and reusable function within your automation projects.

When this trigger is used, the flow can accept custom-defined input parameters, run a series of actions based on the logic you design, and optionally return output values back to the calling (parent) flow. This structure allows for better organization, scalability, and reusability in your automation architecture — especially helpful in large or complex workflows.

🔑 Key Capabilities:

  • Parameterize your flow: Accept dynamic values from the parent flow using custom input parameters (strings, numbers, dates, files, etc.).
  • Run independently: Perform complex logic without depending on external triggers like Forms or Webhooks.
  • Return outputs: Share results back to the main flow using flow variables marked as outputs.
  • Encapsulate logic: Create self-contained logic blocks to simplify and standardize across multiple flows.

This trigger is ideal for building centralized utilities (like data validation, calculations, or document generation) that can be reused across different flows without duplicating logic.



Example Use Cases

1. Break Down Large Flows for Clarity and Maintainability

Use a subflow to isolate sections of a large, complex flow. For example, if your flow includes multiple decision points and nested branches, offload one section (like “Check User Permissions” or “Prepare Document Package”) into a subflow. This makes the main flow easier to manage, debug, and reuse.

2. Reuse Shared Logic Across Multiple Flows

If several flows require the same sequence of actions—like calculating tax, formatting dates, or generating a standardized document—you can build a single subflow and call it from any parent flow. This ensures consistency and saves time on maintenance.

3. ⚡ One of the Great Use Cases: Complex or Large Parallel Processing

When dealing with a loop that contains heavy or complex logic, or you’re looping over more than 500 items (the limit for Zenphi’s Parallel ForEach), you can use a typical ForEach loop and inside it call a Subflow with ‘Run in Parallel’ enabled. This allows you to:

  • Handle large datasets
  • Keep logs and execution per item separate
  • Simplify debugging
  • Execute steps concurrently with more control

💡

This method is especially helpful for integrations, calculations, or file operations that are resource-intensive or conditional.

4. Modularize Approval Processes

Create a reusable subflow to handle multi-level approval logic. You can pass in details like amount, approverLevel, or requestType, and the subflow can return the result of the approval back to the main flow.


⚙️ Configuration

Setting

Input Parameters

Before using your subflow, you’ll need to define the inputs it expects to receive from the calling (parent) flow.

To configure inputs:

Click on “Create Input Parameter” to add as many input values as needed. Each input parameter consists of the following options:

Parameter Name

This is the name used to reference the input inside your subflow. Choose a meaningful name that clearly describes the data it represents (e.g., emailAddress, orderId, isInternalRequest).

Data Type

Select the data type that matches the kind of information being passed from the parent flow. Supported types include:

  • String – for plain text like names, email addresses, or statuses
  • Number – floating point numbers (e.g., 4.75)
  • Integer – whole numbers (e.g., 25)
  • Decimal – for precise financial or scientific values
  • Boolean – true/false values, often used for flags or conditions
  • Datetime – full timestamp information (e.g., form submission time, due dates)
  • File – to pass file references (used when the parent flow uploads or generates a file)
  • Object – a structured data container that can hold multiple named fields of the above types. Ideal for passing grouped data like a customer profile or order details.

🧩 For Object types, you'll define the structure by specifying the internal fields (like mini-parameters) and their data types.

Value Mode

Choose whether the input should accept:

  • Single Value – a single item (e.g., one email address)
  • Multiple Values – a list/array of values (e.g., a list of user IDs, file attachments, or product SKUs)

Default Value (For Single Value Parameters Only)

Optionally set a default value. If the parent flow doesn’t provide this input when calling the subflow, the default value will be used. This is useful when the input is optional or has a common fallback.

Add More Inputs

You can repeat this process to add as many parameters as needed. They will appear as available tokens throughout your subflow, allowing you to build logic that responds dynamically to the incoming data.



Defining Outputs for the Subflow

If you want your Subflow to return values back to the calling (main) flow, you’ll need to define outputs properly. This allows the Run Subflow action in the parent flow to wait for completion and access result data—such as calculated values, status messages, or IDs created during the Subflow execution.

How to Define Outputs:

  1. Go to the “Variables” section of your Subflow (not the trigger settings).

  2. Create the variables you want to return to the parent flow.

  3. For each variable, enable the checkbox “Include in Output.”

    🛈 Enabling this makes the variable accessible to the main flow once the Subflow completes execution.

  4. In your flow logic, use the “Set Variable” action to assign values to these output variables at the right time.

Important Note:

  • In the main flow, once the Subflow is run using the Run Subflow action, the returned data is presented as a JSON-formatted text.
  • To work with individual values from this JSON, use the “Convert JSON to Object” action immediately after the Run Subflow step.
  • This gives you structured access to your outputs (e.g., Output.Status, Output.UserEmail, etc.) which you can use in subsequent steps.

Outputs

The Outputs of the Subflow Trigger represent the data automatically provided when this flow is initiated by another Zenphi flow using the Run Subflow action.

These outputs allow your subflow to access context about the flow instance that called it, what parameters were passed in, and when it started. This information is essential for logging, dynamic logic, and personalized execution.

All these outputs are accessible across the flow using the Token Picker—so you can use them in conditions, actions, expressions, and more.

Here’s a breakdown of the available output fields:

1. Start Time

**What it is:**The exact date and time when the subflow began its execution.

**Why it matters:**Useful for time-based decisions, logging execution timestamps, or auditing how long a subflow takes to complete.

2. Parent Flow

This output contains detailed metadata about the flow instance that invoked this subflow. It includes:

  • Workspace ID: The ID of the workspace the calling flow belongs to.
  • Flow ID: A unique identifier for the parent flow.
  • Flow Version: The version of the parent flow that triggered this subflow.
  • Flow Instance ID: The unique ID of the parent flow's execution instance.
  • Flow Step Execution ID: The exact step (i.e., the 'Run Subflow' action) that initiated this flow.

**Why it matters:**Helpful for advanced use cases where you need to trace where the execution came from, link subflow actions to parent steps, or build more complex, connected systems.

3. Start Parameters

**What it is:**These are the input parameters defined by you in the Subflow Trigger configuration (as covered in the previous section) and passed in from the parent flow during execution.

**Why it matters:**These are the core values your subflow runs on—whether it's a user ID, email, uploaded file, or an object containing structured data. You define these inputs, and they appear here once the flow starts.



Running a Subflow from the Main Flow + Key Notes

Once your Subflow is built and configured, you can easily run it from another Zenphi flow using the Run Subflow action. This allows you to modularize your logic, keep flows clean and organized, and reuse logic across multiple automations.

🛠️ How to Set It Up

  1. In your main flow, drag and drop the Run Subflow action onto the canvas.

  2. In the configuration panel, select your Subflow from the list.

  3. Once selected, the inputs in a section labeled Subflow Start Parameters will appear.

    • These are the input parameters you defined in the Subflow’s trigger.
    • You can hardcode values or dynamically fill them using the Token Picker, pulling from previous steps in your flow.

Run in Parallel Option — What It Does

This powerful setting determines whether the parent flow should wait for the Subflow to finish before continuing:

  • ✅ Enabled (Run in Parallel)

    • The main flow continues immediately, without waiting for the Subflow to finish.
    • Best for scenarios where speed matters and you're not relying on any returned outputs.

    Important: If your Subflow returns outputs and you're trying to use them in the parent flow, do not enable this setting. The parent flow may try to access those outputs before they exist, resulting in errors or null values.

  • 🚫 Disabled (Run Synchronously)

    • The parent flow will pause and wait for the Subflow to complete.
    • Use this when you need to access the Subflow’s outputs in the next steps of the main flow.
    • More reliable for data-dependent workflows or when your Subflow performs important updates or logic.


Example Scenario: Process 3,000 Employee Records in Parallel with Cleaner Debugging

Problem

You manage a large HR system, and every day you need to process thousands of employee records coming from a Google Sheet or database. For each record, you must:

  • Validate employee data
  • Check if they exist in the Zenphi Table
  • If not, create a new record
  • Generate and send onboarding documents
  • Log the actions for each record

The logic inside the loop is complex, and the volume often exceeds 3,000 records—far beyond the 500-item limit of Zenphi’s Parallel ForEach.

Solution Using Subflow Trigger

Instead of writing all logic in one large flow, you:

  1. Create a Subflow that handles one employee record:

    • Input parameters: employee ID, name, email, etc.
    • Inside: check existence, create record if needed, generate docs, log.
    • Output: Duration — The time it took to complete this action (no user-defined outputs, only system-generated ones).

  2. In your main flow:

    • Use a regular ForEach loop to go through all 5,000 employees.
    • Inside that loop, add the Run Subflow action.
    • Select the Subflow and pass the current record's details into the input parameters.
    • Enable Run in Parallel to execute each Subflow instance concurrently.

Why This Works So Well

  • Bypasses the 500-item limit on Parallel ForEach.
  • Each employee process is handled separately, with individual logs and outputs.
  • Easier to debug: if one Subflow fails, you can isolate it without cluttering the main flow.
  • Faster execution since each record is handled in parallel.

You still get clean output from each Subflow (if needed), and can convert it to structured data using Convert JSON to Object.

🔚 Result: You’ve achieved a scalable, maintainable, and efficient solution. Your main flow stays lightweight, and your team can easily locate and fix issues with any specific employee processing instance.

🚧

Zenphi’s Subflow trigger helps you break down heavy processes into smaller, reusable building blocks — while giving you control over performance and reliability.

Updated about 11 hours ago