Understanding the Sub-Zap app

A sub-Zap is a set of actions that can receive data from other Zap workflows and send back the results of their actions. Instead of rebuilding the same steps across multiple workflows, you can create a sub-Zap once and use it within different Zap workflows.

Consider it like a “mini-Zap workflow” designed for specific, repeatable tasks that you can insert into any workflow. A sub-Zap allows you to manage and maintain these tasks in one place, streamlining your automation.

Beta

The Sub-Zap app is a beta feature. It’s available for use, but still in active development and may change.

Available on plans:

Free

Professional

Team

Enterprise

When to use a Sub-Zap

A sub-Zap is most helpful when you have the same set of steps repeated across different Zap workflows. Here are a few examples of ways you can use a sub-Zap:

• Data transformation: Use a sub-Zap to standardize or format data, such as converting dates, calculations, or adjusting text.
• Shared notifications: If you send similar notifications across several apps, a sub-Zap allows you to handle the messaging, ensuring consistency in tone and structure.
• Standardized responses: a sub-Zap works well for predefined workflows, such as customer follow-ups, internal alerts, or status updates.

More examples can be found in this Community post.

Components of a Sub-Zap

A sub-Zap works by receiving data from one or more Zap workflows, processing it through a set of action steps, and sending the results back to the original Zap or Zap workflows.

Each sub-Zap you build must consist of:

• A Start a Sub-Zap trigger: This step defines the data fields the sub-Zap workflow will receive from Zap workflows. You can specify what information from the main Zap you want to pass onto your sub-Zap.
• Actions: Like a regular Zap, the Sub-Zap app can include multiple actions. You can add as many actions as needed.
• Return From a Sub-Zap action: This final step of your sub-Zap sends data back to your Zap workflows.

To interact with a sub-Zap in other Zap workflows, you add the Call a Sub-Zap action to your Zap. This action will:

• Send data from that Zap to your sub-Zap.
• Trigger your sub-Zap to run all its actions.
• Receive data back from the sub-Zap that can be used in any subsequent steps.

Learn how to create a sub-Zap.

Limitations and considerations

• Sub-Zap requirements: All sub-Zap workflows must use the Start a Sub-Zap trigger and have a Return From a Sub-Zap action as its last step.
  • All Paths branches must have a Return From a Sub-Zap step.
• Data must be returned: A sub-Zap must return data. For example, if none of the paths are successful or data is filtered out before returning, the parent Zap run will remain in a Delayed state indefinitely.
  • If you find a parent Zap stuck in Delayed, open the sub-Zap run from that parent Zap and check whether the sub-Zap actually returned any data.
  • To prevent this, add a fallback path to your Sub-Zap. This ensures that if none of the other paths run, the fallback will run and return data to the parent Zap.
• Task usage: Sub-Zap steps do not use any tasks, but the steps within a sub-Zap will if they run successfully.
• Looping: You cannot use a loop step within a sub-Zap.
• Paths:
  • If you use a Return From a Sub-Zap step in more than one path branch, only the first oFe to match will run. Ensure your path branch logic is set so that only one path runs at a time.
  • If more than one path branch runs and both contain a Return From a Sub-Zap step, you’ll see the error “Did you fork or replay this step? We expected callbackUrl to be stored!”.