Hi @Mads!

Thanks for letting us know about this. I can understand that writing validation for incorrectly set up Zaps could be frustrating.

One reason to always provide this on actions is to let users map in fields from other steps. You can imagine a Status field that would only allow values like “New,” “In Progress,” and “Done.” But the user might have an upstream step that would set that field differently based on any number of factors, and so they would want to map the result of that upstream step into that field.

My recommendation on developing apps in this situation is to not necessarily try to protect the user from themselves, but to let the error messages from the API tell the user what’s going wrong. So if there’s an incorrect mapping somewhere that results in the API rejecting it because that value isn’t allowed in that field, make the error message as descriptive as possible to help the user fix their error.

I hope that helps! Let us know if you have any more feedback or questions, and we’ll be happy to take a look.

Hi shalgrim,

Writhing validation is a necessary part of the job, but writing validation for something that should not require it, is frustrating, extra work and quite possibly could mean more customer support. I gather, from your recommendation, that you're not completely in line with the advise, from the linked post, and having the receiving API respond to incorrect data, does makes more sense IMO - it just doesn't fix the issue at hand.

I can certainly understand why it might be wanted, to include data from previous steps, in some cases, but the key word here is might. It’s just very counterintuitive (for us and our users), to include an option that possibly breaks functionality - just because it might be needed, in an another situation. This is precisely why an option to disable/remove the field, is the best solution for all, making us able to customize the Zap creation exactly as needed.

I absolutely agree that the API must be able to respond to incorrect data, but in this case, it’s still trying to fix something that’s needlessly broken, by giving users an option to input incorrect data, in the first place. A strictly defined list should not offer an option to deviate from the defined data.

In my experience, it’s far better to guide users through setting up things, by not letting them choose what will not work. It’s just less work and frustration for them and us. Most user does not want (nor have the insight) to set up elaborate and complex Zaps - they need a straight forward way to connect two systems, for simple exchanging of data.

I hope you’ll reconsider this.