I have a fairly complex zap logic and in general my zap is working well. The flow of the zap logic is such that after a number of successful steps, I place a filter step, and only those events that filter through successfully get executed further. In my scenario, this filter is applied for 95% cases, with only 5% cases passing through.
For example, I receive a list from the source system, and my filter checks if it’s an empty list. If not, then there is a loop (Loop by Zapier) to iterate through each list element, and the destination system is updated with the element value. If the list is empty, of course, then the filter kicks in and the Loop step onwards are avoided. Note, there are a few successful steps executed before this, including one update into the destination system.
My annoyance is that in my zap history or status, this zap is showing “Filtered” -- whereas I would prefer for it to show “Success”. After all the logic did execute successfully. Here’s why this matters: in a high volume environment, when an admin is trying to track the status of the zaps, these reports are spooking the analytics and leading the team to spend cycles investigating successful events.
I may be wrong, but for some other zaps that have a similar filter, which kicks in less than 5% times, the zaps are showing success. In these cases, the filter is preceded by a PATH step within a zap. Could that be affecting the status reporting?
I am aware that this may not be easy to “tweak” -- but I would like to. For now, I do wish to report that this is a wrong and misleading success report by zap that is not having an actual failure in data integration, but is causing confusion when it comes to administration, and I hope Zapier understands this.
I would love to hear back from Zapier support on their take on this.
Some ways to help put this in context.
Look at the number of Tasks used by a Zap Run: https://zapier.com/app/history
You could establish some guidelines for those looking at the Zap Runs.
For example, if a Zap Run has X Tasks, then that means Y.
Regarding your question about Zap Runs with Paths, the answer is it depends on how the Paths process.
Multiple Paths can be run if the Filter conditions match for a given Zap.
A possible alternative Zap config...you can split the Zap and chain Zaps together using Webhooks.
NOTE: This is a simplified example.
Zap 2 (essentially 1 per path)
This way Zap 1 should always end in either a success
This way Zap 2 can process independently of Zap 1
Note you may need multiple Zap 2s, one for each desired “path”
@ClayPotter! I wanted to pop in and see how you were getting along with some of @Troy Tessalone’s recommendations. 🙂
Keep us posted!
@christina.d : The zap is in production and is doing heavy weightlifting for some time, therefore it does not look like I will be able to actually implement the workarounds given by @Troy Tessalone - however I do believe they will serve as workarounds. I appreciate Troy’s help because as an outsider who cannot fix Zapier product, he did what he can -- which is to suggest a workaround. Let’s not confuse a workaround for a product fix.
However, I do want Zapier support and product managers to understand that I pointed out a possible weakness in the product’s admin user experience. As someone who is familiar with admin environments, I would like to take this opportunity to point out that Zapier could/should improve their error reporting and related admin interface. It is quite minimal right now and frankly it’s a pain to debug zaps.
Best to submit feedback and feature requests via a ticket to Zapier Support in order for them to be properly logged: https://zapier.com/app/get-help
Thank you for sharing your experience with the Filter success/error reporting process and I’m sorry that it’s been so frustrating for you. I’ve passed your feedback on to the product team.