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!
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.