I don’t understand how adding a filter to a zap qualifies it as having been changed too much.
thereby preventing replay in case of error, and making the retroactive fixing of zaps a nightmare.
Can somebody in the know please explain this design choice? I’m only talking about adding a filter,
which is not destructive, and will either cause the next (unchanged) step to execute, or not.
Thanks for any insight.
Hi
It’s not so much a choice as a by-product of the way that the platform is engineered. Adding a step changes make-up of the Zap to the degree that it’s not possible to replay the step, even if that step is Filter step.
Essentially, the task history has a script of what steps it needs to run to re-play those tasks, based on how the Zap ran the first time. When you replay a Zap it will try to run through all the steps it knows where there before. If it is trying to run through those but hits a new action, it doesn’t know how to move forward and so wont be able to continue.
I’m sorry for the frustration with that!
Hi
Any time that you add or remove a step from a Zap, you wont be able to replay a task as the structure of the Zap (the of steps in it) has changed.
The most common use for replaying tasks is if a connected app experienced a temporary error, causing the Zap to hit an error. When the app is running as normal, replaying the tasks will allow them to work as they should.
I hope that clears things up!
Can you give me an example, please? This is a point of contention for us.
Thanks,
Martin.
Hi
I just wanted to check in with you to see if you’d managed to get things working, or whether you could still use some help here. Please let us know :)
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.