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:
- (Trigger step and previous action steps as needed)
- Use Storage by Zapier to set a variable (Storage Key) to 0
- Run the step that might fail (Google Sheets, webhooks, “find/search” etc)
- Use Storage by Zapier to set the same variable (Storage Key) to an output of the previous step
- Use Storage by Zapier to “get value” of the Storage Key
- 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 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.
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!