Skip to main content

Reference: 

 

Problem

This is likely simpler than it seems but the naming is hurting my brain.

When I think “Sub-Zap” I think “sub-function” - meaning I can build a function with fields and simply call the function from the sub (i.e. getNames(User.first, User.last) where “first” and “last” are variables in some other place called “User”). 

Here’s the issue.

If your Trigger is what gives you the fields you need, I’m not seeing a way to “pass” that data over to Sub-Zap at all, and I suspect it’s simply the name of this that’s confusing.

Here’s the “Pseudo-code” for what I need to happen.

 

When a new item is detected in an RSS feed, get the fields you need, then call a series of Sub-Zaps that do different stuff with those fields.

 

It’s not a branch because there’s no conditional - in my mind. It’s delegating the work to separate Sub-Zaps where I can easily bolt on additional workers as needed for that same data.  Which is what I assume is the benefit of this.

Getting the RSS part is a trigger - fine.

Action - call a Sub-Zap - fine.

But then on the other side, I don’t see a way to “give” that Sub-Zap the fields from the first Zap so it can do what it needs to do.  It looks like what it instead wants to do is:

 

Based on whatever event, call a Sub-Zap that does whatever trigger it needs to get the data they need to work from.

 

The problem is, there’s no other event than the new item in RSS.  Which has to be trigger, because the action doesn’t allow me to test to know when it’s there and it could be there at any point during the day, plus I need to avoid duplicate executes, which means it needs to trigger on new so it knows not to do that.

 

I CAN call the RSS again on each Sub-Zap, but that feels inefficient.  That means I’m repeatedly calling the same RSS for information the system already is (or should be) aware of.  I could do that now without Sub-Zap.

Is there no way to just pass fields to the Sub-Zap where that data comes directly from the first trigger?

Hi @ctrstage 

Good question.

Sub-Zaps when called run and return data back to the main Zap.

The fields a Sub-Zap expects need to be configured on the Sub-Zap first, before fields on the main Zap can be mapped to the Sub-Zap.

Admittedly, Sub-Zaps are a bit cumbersome to configure and test.

Help article about Sub-Zaps: https://zapier.com/help/create/other-functions/build-reusable-sub-zaps

 

###

 

Alternatively, you can chain Zaps together using Webhooks to achieve the concept of Sub-Zaps: https://zapier.com/apps/webhook/help


Hi @ctrstage 

Good question.

Sub-Zaps when called run and return data back to the main Zap.

The fields a Sub-Zap expects need to be configured on the Sub-Zap first, before fields on the main Zap can be mapped to the Sub-Zap.

Admittedly, Sub-Zaps are a bit cumbersome to configure and test.

Help article about Sub-Zaps: https://zapier.com/help/create/other-functions/build-reusable-sub-zaps

 

###

 

Alternatively, you can chain Zaps together using Webhooks to achieve the concept of Sub-Zaps: https://zapier.com/apps/webhook/help

 

That’s what I was afraid of.

It feels like Zapier doesn’t have a simple way of dealing what I think is a simple use case - and should be usable for laymen workers when I’m not around.  Getting into webhooks now requires different levels of knowledge (more expensive levels).

I hope they enhance this to do it the way I pseudo-described, which is simply to get data from a trigger and be able to pass it to another zap to take separate action from so that it’s truly reusable but also visually simple without needing to be an “IT guy”.


@ctrstage

Think of a Sub-Zap as an API Endpoint or a Code function.

Both need to exist first and expect certain predefined parameters in order to return results.

 

Best to share feedback and feature requests by submitting a ticket via Zapier Support to be logged: https://zapier.com/app/get-help


Hey @ctrstage !

I’m Tina, a Product Designer at Zapier.

We are aware of some of the issues you’re describing and my team is currently working on a new solution to try to address them. We will be going into testing soon, if you’re interested we could look into having you as a potential participant in our study. Let me know how that sounds!
 


Hey @ctrstage !

I’m Tina, a Product Designer at Zapier.

We are aware of some of the issues you’re describing and my team is currently working on a new solution to try to address them. We will be going into testing soon, if you’re interested we could look into having you as a potential participant in our study. Let me know how that sounds!
 

Happy to help. Can almost guarantee I’m not the only one with at least the basic need (simple way to pass data from TriggerAZapA-to-TriggerBZapB) and opens up a wide variety of possibilities for using RSS in very cool ways.

Thank you.

For now I’ll just have to build the separate Zaps and deal with it that way.


@ctrstage 

You may want to look more into Webhooks: https://zapier.com/apps/webhook/help

Webhooks in Zaps function as triggers (Catch Hook) and actions (GET/POST/etc).

Webhooks can be used to chain Zaps together.

NOTE: Unlike a Sub-Zap sending data to another Zap with a Webhook is like a jump off point, rather than a feedback loop to the originating Zap.

Here’s a trick to send all data from one Zap step to another Zap using a Webhook - POST action (see description):

 


@ctrstage

You may want to look more into Webhooks: https://zapier.com/apps/webhook/help

Webhooks in Zaps function as triggers (Catch Hook) and actions (GET/POST/etc).

Webhooks can be used to chain Zaps together.

NOTE: Unlike a Sub-Zap sending data to another Zap with a Webhook is like a jump off point, rather than a feedback loop to the originating Zap.

Here’s a trick to send all data from one Zap step to another Zap using a Webhook - POST action (see description):

 

 

Again, what I come up with should not require advanced technical knowledge to maintain.

A laymen user won’t understand “JSON” or any other such.  It’s not the right answer.

The whole pitch behind Zapier is NOT to think about code for 80% of use cases.

What @tina-feijoo is alluding to solves the larger concern - KISS: Keep It Stupid Simple.

Webhooks might be simple to a tech guy.  They won’t be for some admin assistant.

Solutions need to be workable to the lowest common denominator when the need is a simple one (pass data to something else).

Even basic HTML can do this.