Skip to main content

Get Support
Have a question? Let's get you an answer!

How Do I...? Troubleshooting Code & Webhooks Developer Zone

Other Help Resources
Wait, there's more! Check out these Community sourced spaces for additional resources.

Zapier Help Center Hire an Expert

Learning Resources
All of our best learning resources can be found here.

Featured Articles Show & Tell Zapier's products AI Hub Zapier Tools Hub

Share your knowledge
Give back to the Community by sharing your automation wins and helping to answer questions.

Share your success See unanswered questions User Groups

Other Learning Resources
Some of our favorite additional ways to upskill your Zapier knowledge.

Zapier Learn Zapier Blog Zapier Webinars

Product Updates
Check out what is new and upcoming with Zapier with our regular product updates.

Product Updates

Early Access Program
Want to join Early Access? Learn more here.

I’ve run into this often and have a decent work around so by posting it here hopefully this can help others. 

The issue: Zapier steps that “depend” on the output from a previous step will fail if the previous step fails or has an issue. 

This can happen for a number of reasons, like the webhook step had an error, or (and this has been happening A LOT lately) an app like Google Sheets responds with an error like 500 “Server Error time out”. 

Or a search step fails and you don’t want to create a record Or the application doesn’t give you that option. 

I want to make my zaps smarter and to work around these issues. As you’ll see below It takes a number of extra steps and paths to do this, so I only do it on critical zap steps or where failures are common. 

For example if I try to post to a Google Spreadsheet and I get a time out error I want the zap to take a delay and then make another attempt. Or if there was a failure in finding a row or a contact or whatever the search was I want the zap to take a different path. 

However, and this is where the issue happens, if I have a filter or a rule in a path set up that checks the results of that step it will NOT run because that step/filter/rule “depends” on the output of a previous step that failed, even if the “test” in the filter/rule is to see if the output exists or not.

That’s right! If you check to see if the output of a step does not exist you are now “depending” on that step running. 

So my team and I came up with a beautiful little workaround/hack. And I’ll explain it here. If you have questions or it’s not clear please ask and I’ll explain!

The solution in bullet points:

  1. (Trigger step and previous action steps as needed)
  2. Use Storage by Zapier to set a variable (Storage Key) to 0 
    I typically use some Key name from the trigger step, in this case it’s an ID field
    ​​ which will remain constant through the zap instance and not overlap with other instances of this zap​

     

  3. Run the step that might fail (Google Sheets, webhooks, “find/search” etc)
  4. Use Storage by Zapier to set the same variable (Storage Key) to an output of the previous step 
    This step relies on the step to return successfully. If there is any error in the step giving us this value (“B: Values cleard 6. Text” in this case) this step would not run so the storage value would not change.

     

  5. Use Storage by Zapier to “get value” of the Storage Key 
    We cannot rely on the previous step to run sucessfully so we need an additional step that is not dependent upon that step. So this will run no matter what failed in front of it.

     

  6. Use Paths (Rules) or a Filter here that checks the value of Storage Key. If Storage Key is 0 then #3 above failed, if Storage Key is anything other than 0 step 3 ran sucessfully. 
    The filter I have here is to continue only if the step failed (and the storage value is still 0) you could use the opposite (only continue if the value is NOT 0) and you could use both in separate paths.

     

The explanation

The key is dependency, since Step 3 listed above will fail, then step 4 will not run because it depends on step 3. 

So now we have a scenario where if Step 3 fails step 4 won’t run, so your zap will skip from step 2 to step 5. Step 2 is setting the Storage Key to 0 and Step 5 is retrieving that Storage Key which will still be 0. 

Special Note, I had originally speced this out to not contain step 5. However, my team pointed out that if I used the output of step 4 in my filter/rules those would not run because step 4 didn’t run. So we do need to grab the output of the Storage Key in a separate step even though when step 3 and 4 run successfully the output of step 4 would contain the value of Storage Key. 

This is the full workaround with step 30 in the screenshot = #2 in the list above, and step 31 = #3 in the list etc. You’ll see that after step 34 (the filter step) I re-run my step 31 “Split file Repeat” -- you could use this logic to do a bunch of stuff, including paths or just a re-attempt.

I’ve used this combined with a delay step to “retry” the prone to failing step, if the storage key is 0 I delay and then run the same sequence over again in the path

  • storage key set value to 0
  • run problematic step
  • set storage key to the output of the problematic step
  • get the value of storage key
  • use rules/filters to determine what to do next.

I’ve even set this up to make a total of three attempts before alerting the team that the problematic step did not run after 2 delays and a total of 3 attempts. 

Enjoy and good luck! Hopefully this inspires you to develop more workarounds!

Really love this @PaulKortman - thanks for sharing!

Brilliant! just what I was looking for Paul! Infinity (Monday-like CRM) hasn’t built their “find” function very well, so this was vital to update our records!

this is good stuff, if only we could branch the logic and say, retry if failed, but if value found, continue to the next step. 

What’s the end count of tasks after that whole flow executes successfully?

Awesome workaround. I wish Zapier would fix the underlying problem and allow to check the status of the previous task.

If you have Paths, you can use a Path with the condition: “Can continue” of the previous step. This way you can branch it in two. 

You can only use Path if the previous step exits gracefully. If you want to do a certain step only when the previous steps throws an error, it will crash the whole zap.

 

Also as smart as this workaround is, Zaps will automatically turn off after a certain number of errors. Hoping Zapier adds proper error handling soon. Zapier manager trigger is not a solution because it happens outside the context of the zap that triggered the error.

Just discovered this workaround and it is AWESOME. Thank you for sharing!!

Hi @PaulKortman , Thanks for sharing this workaround. I tried it but not able to complete because I did not understand step: 31. Split File & Step 35. Split file repeat. It would be great if you can show that step (elaborate) in flow chart

Reply


Terms & Conditions